The hottest Software Architecture Substack posts right now

And their main takeaways
Category
Top Technology Topics

Party of One for Code Review!

Software Design: Tidy First? • 3115 implied HN points • 26 Dec 25
đź•ą Technology Software Architecture
  1. Formal, rigorous inspections were too heavy, and the lighter code-review practices that replaced them often become shallow when reviews are asynchronous or rubber-stamped.
  2. AI-driven code generation produces changes faster than human reviewers can keep up, breaking the assumption that another person will catch problems before they compound.
  3. Review's role is shifting toward quick sanity checks and preventing structural drift so the codebase stays understandable by both people and AI, and automated tools that summarize changes and learn project patterns can help bridge the gap without replacing human pairing.

What It Actually Takes to Build a Data Pipeline System

SeattleDataGuy’s Newsletter • 718 implied HN points • 14 Jan 26
đź•ą Technology Software Architecture
  1. A reliable pipeline system needs many core components—secure secrets and connection management, rich logging and monitoring, dependency tracking, execution routing, scheduling, data quality checks, pipeline definitions, and a usable UI—because missing any of these creates ongoing operational headaches.
  2. Operational practices like idempotency and easy backfilling, clear ownership, alerting/on-call routing, and environment isolation are critical so reruns don’t create duplicates and failures get handled quickly.
  3. Most teams should prefer existing tools unless they have a clear reason to build. If you do build, explicitly scope features—like compute routing or AI integrations—and plan for long‑term maintenance.

How did Facebook design their Real-Time Processing ecosystem

VuTrinh. • 279 implied HN points • 17 Aug 24
đź•ą Technology Software Architecture
  1. Facebook's real-time data processing system needs to handle huge amounts of data quickly, with only a few seconds of wait time. This helps in keeping things running smoothly for users.
  2. Their system uses a message bus called Scribe to connect different parts, making it easier to manage data flow and recover from errors. This setup improves how they deal with issues when they arise.
  3. Different tools like Puma and Stylus allow developers to build applications in different ways, depending on their needs. This means teams can quickly create and improve their applications over time.

Spec-Driven Development: From Vibe Coding to Structured Development

Bit Byte Bit • 65 implied HN points • 25 Feb 26
đź•ą Technology Software Architecture
  1. Write a clear, versioned specification before asking an AI to implement a feature so the AI has a single source of truth and won’t make inconsistent architectural or security choices.
  2. Use purpose-built SDD tooling that fits your workflow and codebase; tools that produce spec deltas, a living spec, and an auditable archive make it easy to resume, verify, and evolve work.
  3. SDD reduces rework and improves cross-role review, but it has costs — don’t use it for trivial fixes or pure prototyping, keep specs lean, and watch for spec bloat, drift, and review fatigue.

Diving Deep into LinkedIn's Data Infrastructure: My 6-Hour Learning & Key Takeaways

VuTrinh. • 299 implied HN points • 03 Aug 24
đź•ą Technology Software Architecture
  1. LinkedIn's data infrastructure is organized into three main tiers: data, service, and display. This setup helps the system to scale easily without moving data around.
  2. Voldemort is LinkedIn's key-value store that efficiently handles high-traffic queries and allows easy scaling by adding new nodes without downtime.
  3. Databus is a change data capture system that keeps LinkedIn's databases synchronized across applications, allowing for quick updates and consistent data flow.
Get a weekly roundup of the best Substack posts, by hacker news affinity:

Preparing for a world where humans don’t write code

Brick by Brick • 72 implied HN points • 09 Feb 26
đź•ą Technology Software Architecture
  1. AI agents will increasingly write production software autonomously, making human code writing and review a bottleneck and causing many current development practices to stop scaling.
  2. Trust should come from continuous validation, observability, scenarios, and invariants rather than relying on humans to read code, and code should be treated as disposable when generation is cheap and continuous.
  3. Organizations should create small AI-first teams that build real production systems under strict constraints (no human-written or human-reviewed code) to learn what breaks, then let successful practices spread while humans focus on intent, constraints, and outcomes.

Hype cycles

Bite code! • 10520 implied HN points • 24 Jun 23
đź•ą Technology Software Architecture
  1. XML was once believed to be the future, but turned out to create technical debt instead.
  2. Following every hype blindly in technology can lead to failed projects and waste of money.
  3. Using the right tool for the right job is crucial in software development, avoiding unnecessary complexity and costs.

The Hadoop Distributed File System

VuTrinh. • 259 implied HN points • 18 May 24
đź•ą Technology Software Architecture
  1. Hadoop Distributed File System (HDFS) is great for managing large amounts of data across many servers. It ensures data is stored reliably and can be accessed quickly.
  2. HDFS uses a NameNode that keeps track of where data is stored and multiple DataNodes that hold actual data copies. This design helps with data management and availability.
  3. Replication is key in HDFS, as it keeps multiple copies of data across different nodes to prevent loss. This makes HDFS robust even if some servers fail.

Nature's many attempts to evolve a Nostr

Subconscious • 2095 implied HN points • 13 Oct 24
đź•ą Technology Software Architecture
  1. Centralized apps control user data and accounts, making users dependent on their servers. This creates a situation where users can be locked out at any time.
  2. Federated systems allow users to choose servers, but can still lead to centralization as large nodes dominate, limiting true user independence.
  3. Peer-to-peer networks promote equality among users, but they often evolve to create 'superpeers' that can mirror centralization, so a new approach using relays could improve user control and ownership.

Transaction-Oriented Programming

Burning the Midnight Coffee • 64 implied HN points • 15 Nov 25
đź•ą Technology Software Architecture
  1. Transaction-Oriented Programming focuses on breaking down tasks into user-relevant units of work, which can help structure software and make error handling clearer.
  2. Each unit of work should be treated as a transaction, ensuring it is either completed fully or not at all, which can improve reliability in software applications.
  3. Implementing ACID properties (Atomicity, Consistency, Isolation, Durability) helps maintain integrity in software, especially when errors occur, making it easier to manage transactions.

Designing Instagram's Video Uploads: Optimizing for Low Latency and scalability

Engineering At Scale • 255 implied HN points • 20 Jan 25
đź•ą Technology Software Architecture
  1. Instagram's video upload system needs to handle millions of uploads daily while keeping the process fast and efficient. It converts videos into different formats for users with varying internet speeds.
  2. The system can be designed in approaches, starting from simple methods to more complex asynchronous solutions. Improving reliability and speed is key to making the service work better.
  3. Using segmented video uploads allows faster processing. By uploading smaller parts of the video, the service can work on them at the same time, reducing wait times for users.

Single Tenant vs Multi Tenant Architecture for SAAS Platforms [System Design Sundays]

Technology Made Simple • 139 implied HN points • 04 Dec 23
đź•ą Technology Software Architecture
  1. Single Tenant Architecture provides each customer their own independent database and software instance, offering security and customization like living in a detached house.
  2. Multi-Tenant Architecture is akin to an apartment building where multiple tenants share common infrastructure, allowing for economies of scale but potentially limiting customization.
  3. Single Tenant architecture is known for high user engagement, control, and stability, while Multi-Tenant architecture favors compliance, security, and quick onboarding for better scalability.

I spent another 6 hours understanding the design principles of Snowflake. Here's what I found

VuTrinh. • 79 implied HN points • 10 Feb 24
đź•ą Technology Software Architecture
  1. Snowflake separates storage and compute, allowing for flexible scaling and improved performance. This means that data storage can grow separately from computing power, making it easier to manage resources.
  2. Data can be stored in a cloud-based format that supports both structured and semi-structured data. This flexibility allows users to easily handle various data types without needing to define a strict schema.
  3. Snowflake implements unique optimization techniques, like data skipping and a push-based query execution model, which enhance performance and efficiency when processing large amounts of data.

3 quick tips on how to build more scalable systems [System Design Sundays]

Technology Made Simple • 119 implied HN points • 17 Apr 23
đź•ą Technology Software Architecture
  1. Location matters: Place software close to clients for faster response times using CDNs, edge computing, or geo-replication.
  2. Cache wisely: Optimize speed by using in-memory caching, database caching, or web caching to avoid repeated actions.
  3. Async is key: Improve efficiency with asynchronous processing through message queues, event-driven architectures, or microservices.

Monoliths vs Microservices [System Design Sundays]

Technology Made Simple • 99 implied HN points • 24 Oct 22
đź•ą Technology Software Architecture
  1. Monolith architecture involves building and maintaining all components together, requiring a full rebuild when changes are made.
  2. Microservices architecture deploys and maintains different parts of the system independently, allowing for scalability and flexibility but requiring careful planning.
  3. Monoliths offer simplicity and easier testing, while Microservices provide scalability and quicker deployment but demand more setup effort and planning.

Good data engineers are lazy

Data People Etc. • 213 implied HN points • 30 Mar 23
đź•ą Technology Software Architecture
  1. Good data engineers strive for automation to be as lazy as possible.
  2. Reevaluate the necessity of tools in the data stack and aim for streamlined, efficient systems.
  3. Declarative paradigm and proper architecture design are crucial for data engineers to optimize efficiency and consistency.

Clean Architecture the Right Way

🔮 Crafting Tech Teams • 19 implied HN points • 02 Aug 23
đź•ą Technology Software Architecture
  1. Clean Architecture is not just about the folder structure, it involves more practical considerations beyond that.
  2. Copying someone else's 'ideal, clean architecture' may not be the right approach; understand the underlying reasons for implementing Clean Architecture.
  3. To truly grasp the essence of Clean Architecture, focus on the practical aspects and implications rather than just the superficial folder structure.

Everybody Wants to Have an API Product

The API Changelog • 1 implied HN point • 07 Jan 26
đź•ą Technology Software Architecture
  1. Treat API-as-a-Product as a journey, not a final destination. Most teams start with quick, use-case APIs and need deliberate practices to evolve toward reusable, product-grade APIs.
  2. Keep gateways limited to simple infrastructure tasks like protocol or format transformations. Avoid encoding business authorization or core decision logic in the gateway; those belong in identity providers or backend services.
  3. Use a framework like the Data Interface Quadrants to classify APIs as raw data, composed, BFFs, or reusable data products. Classifying APIs makes their purpose measurable and guides what you must change to make them reusable and consumable by others.

The effects of splitting a project into multiple teams[Systems Design Sundays]

Technology Made Simple • 39 implied HN points • 18 Apr 22
đź•ą Technology Software Architecture
  1. As projects grow, you may need multiple teams to handle different components, changing how you work from being in one team to collaborating across teams.
  2. Conway's Law emphasizes that a system's design structure mirrors the organization's communication structure, highlighting the importance of how teams interact when developing a project.
  3. Learning about the risks in current software architecture design approaches can help in adapting and improving your skills for dealing with larger project scopes.

A Dispatch On All Things Tools

Building Rome(s) • 7 implied HN points • 11 Sep 23
đź•ą Technology Software Architecture
  1. Building timelines can be frustrating due to lack of ideal tools like Gantt charts or whiteboarding tools.
  2. C4 Diagrams are a great visual language to discuss software architecture for TPMs and PMs.
  3. There is a desire for an all-in-one tool to manage product development, simplifying the use of multiple tools like Slack, Linear, Coda, Figma.

AWS Lambda: Pitfalls

Unlearning • 6 implied HN points • 08 Jul 23
đź•ą Technology Software Architecture
  1. Avoid creating Lambda monoliths to improve performance and cost efficiency.
  2. Be cautious of Lambdas calling other Lambdas to prevent increased costs and potential bottlenecks.
  3. Design Lambdas to be idempotent to avoid data duplication and ensure system reliability.

Data is not a Microservice

Data Products • 1 HN point • 07 Jul 23
đź•ą Technology Software Architecture
  1. Data requires a source of truth that microservices cannot inherently provide without a shift in software engineering practices
  2. Not all data is equally valuable, so treating all data as microservices can be costly and restrictive
  3. The data development lifecycle differs from software development, requiring flexibility, reuse, and tight coupling that conflict with typical microservices architecture

Stability Begets Tests

Tribal Knowledge • 0 implied HN points • 03 Jul 22
đź•ą Technology Software Architecture
  1. Tests are only valuable when you already have stability in your product.
  2. Focus on developing a stable core set of features before investing heavily in testing.
  3. Design features for a smaller customer base initially to work out kinks and build a sustainable product.