The hottest Systems Architecture Substack posts right now

And their main takeaways
Category
Top Technology Topics

Layer by Layer, We Built Data Systems No One Understands

SeattleDataGuy’s Newsletter • 706 implied HN points • 02 Mar 26
🕹 Technology Systems Architecture
  1. Layering tools and roles keeps adding complexity until systems become fractal sprawl that’s costly and hard to maintain.
  2. Buying managed platforms can replace people and speed delivery short-term, but it often buries business logic and makes it harder to connect technical work to business outcomes, so teams tend to add even more layers.
  3. Before adding any new layer, ask what problem it solves, what happens if you don’t add it, and who will own it in six months—if you can’t answer, you’re creating liability instead of leverage.

Apache Kafka - Overview

VuTrinh. • 539 implied HN points • 06 Jul 24
🕹 Technology Systems Architecture
  1. Apache Kafka is a system for handling large amounts of data messages, making it easier for companies like LinkedIn to manage and analyze user activity and other important metrics.
  2. In Kafka, messages are organized into topics and divided into partitions, allowing for better performance and scalability. This way, different servers can handle parts of the data at once.
  3. Kafka uses a pull model for consumers, meaning they can request data as they need it. This helps prevent overwhelming the consumers with too much data at once.

The LLM Context Tax: Best Tips for Tax Avoidance

Nicolas Bustamante • 104 implied HN points • 11 Feb 26
🕹 Technology Systems Architecture
  1. Context tokens are expensive and degrade performance as they accumulate, so treat context as a scarce resource and keep prompts stable and append-only; move dynamic pieces (like timestamps) to the end so you preserve KV cache hits.
  2. Architect agents to minimize tokens by storing tool outputs as files, using precise two-step tools that return metadata before full content, delegating work to cheaper subagents, reusing templates, batching or parallelizing tool calls, and caching common responses at the application level.
  3. Clean and compact data before sending it to the model, place critical information at the beginning or end to avoid the lost-in-the-middle problem, use summarization/compaction before hitting pricing cliffs, and set strict output token limits to control costly outputs.

Apache Kafka - Important Designs

VuTrinh. • 259 implied HN points • 13 Jul 24
🕹 Technology Systems Architecture
  1. Kafka uses the operating system's filesystem to store data, which helps it run faster by leveraging the page cache. This avoids the need to keep too much data in memory, making it simpler to manage.
  2. The way Kafka reads and writes data is done in a sequential order, which is more efficient than random access. This design improves performance, as accessing data in a sequence reduces delays.
  3. Kafka groups messages together before sending them, which helps reduce the number of requests made to the system. This batching process improves performance by allowing larger, more efficient data transfers.

The Over-Engineering Trap

Tech Ramblings • 39 implied HN points • 28 Jul 24
🕹 Technology Systems Architecture
  1. Simplicity and maintainability are more important than performance and complexity in software design. Focus on creating code that's easy for others to understand and work with.
  2. Avoid over-complicated platforms like microservices, especially if your application doesn't need them. Start with basic tools and scale only when necessary.
  3. Your goal as a software engineer should be to deliver a product that customers can use easily. Keeping things simple helps with maintenance and helps new team members get up to speed faster.
Get a weekly roundup of the best Substack posts, by hacker news affinity:

Yes, you need to duplicate your frontend business logic on the server

Bite code! • 978 implied HN points • 13 Oct 24
🕹 Technology Systems Architecture
  1. Always have your business logic on both the frontend and the server. If you only trust the client side, you risk getting incorrect data.
  2. Your server needs to handle requests from various sources, including non-standard browsers and bots. These can bypass your frontend checks if they're not replicated on the server.
  3. Any important checks for security and data integrity should happen on the server to prevent unexpected issues. This means you'll often have to duplicate checks that you already do on the frontend.

The term "technical debt" is bad, and we should feel bad

Bad Software Advice • 82 implied HN points • 21 Jul 25
🕹 Technology Systems Architecture
  1. The term 'technical debt' can confuse people and isn't very helpful. It makes it sound like a mistake when it’s often just how things change over time.
  2. Technical projects often struggle for attention because they're not seen as urgent or important compared to other tasks. This makes fixing issues harder.
  3. Instead of thinking about technical problems as debts to be paid back, we should see them as regular maintenance needed to keep things working well and up-to-date.

Faster computers afford dumber solutions

Wednesday Wisdom • 104 implied HN points • 18 Dec 24
🕹 Technology Systems Architecture
  1. Faster computers let us use simpler solutions instead of complicated ones. This means we can solve problems more easily, without all the stress of complex systems.
  2. In the past, computers were so slow that we had to be very clever to get things done. Now, with stronger machines, we can just get the job done without excessive tweaking.
  3. Sometimes, when faced with a problem, it's worth it to think about simpler approaches. These 'dumb' solutions can often work just as well for many situations.

Enterprise General Intelligence: The Emergent Mind of Organizations

Nano Thoughts • 1 implied HN point • 02 Feb 26
🕹 Technology Systems Architecture
  1. Companies need a nervous system — continuous sensing, shared memory, and homeostatic regulation — not a single omniscient center, so drift gets detected and corrected early.
  2. Culture is the organization's decision procedure, so make decision logic visible and teachable. Provide contextual memory that surfaces the right information at the moment of choice and traces provenance to resolve conflicts.
  3. Build a continuous, stateful, symbiotic system with clear governance and privacy (including a right to forget) rather than a stateless rented model or surveillance tool, because surveillance drives real thinking underground.

GroupBy #6: Meta developer tool, trillions of data points at Discord and Uber's data cycle management

VuTrinh. • 19 implied HN points • 24 Oct 23
🕹 Technology Systems Architecture
  1. Meta has introduced developer tools that help manage large-scale projects efficiently. These tools assist engineers in solving problems and improving systems.
  2. Big companies like Discord and Uber are using massive data points to create valuable insights. This helps them to effectively manage their data and understand trends better.
  3. Data engineering continues to evolve, with tools like BigQuery and dbt Mesh enhancing data practices. Staying updated with these tools can improve data analysis and management.

GroupBy #5: The story of S3, Kafka at scale and the boring is back

VuTrinh. • 19 implied HN points • 17 Oct 23
🕹 Technology Systems Architecture
  1. S3 is a big storage system used for data, and understanding how it's built can help improve data handling. It's cool to know how tech like this works.
  2. Running Kafka at scale is interesting, especially for companies like Pinterest. It shows how important reliable data flow is in tech.
  3. There's a trend of making things simpler and more efficient in engineering. Sometimes, going back to basics can solve complex problems.

State Must Live With the Agent

domsteil • 0 implied HN points • 12 Jan 26
🕹 Technology Systems Architecture
  1. Commerce built around remote services breaks when autonomous agents execute and retry at scale, so state must live where decisions are made to avoid duplication, corruption, and ambiguous outcomes.
  2. Safe autonomous commerce requires embedding execution and local persistence inside agents, with deterministic state transitions, idempotent commands, and event-sourced histories so actions are replayable and resilient offline.
  3. This is a fundamental architectural shift: commerce should behave like a local database (iCommerce) with network sync and settlement as secondary roles, not an optional optimization, to enable reliable agent-driven economies.

LLamaIndex Agentic RAG Demo

Cobus Greyling on LLMs, NLU, NLP, chatbots & voicebots • 0 implied HN points • 01 Feb 24
🕹 Technology Systems Architecture
  1. Agentic RAG uses a system of smaller agents to answer questions across multiple documents. Each smaller agent focuses on its own document, which helps organize the information better.
  2. This setup allows for comparing different documents and summarizing specific ones easily. It's a flexible way to dig into complex topics.
  3. The architecture is designed to scale by adding more agents as needed. This means it can grow and adapt to handle more information over time.

Building a Fly.io-like Scheduler Part 1: Basic Coordinator and Workers

aspiring.dev • 0 implied HN points • 23 Feb 23
🕹 Technology Systems Architecture
  1. Fly.io uses synchronous scheduling, meaning you either get a compute resource when you ask for it or you don't. This makes it simpler to handle workloads like serverless functions.
  2. The scheduler's design allows workers to manage their own availability, removing the need for a separate database. This lets workers freely join or leave the system without issues.
  3. In this system, a coordinator requests and schedules tasks on available worker nodes. The first worker to respond gets the task, making it efficient for various jobs like running Docker containers or AI inference.

First-Class Models: The Missing Productivity Revolution

FREST Substack • 0 implied HN points • 26 Jun 25
🕹 Technology Systems Architecture
  1. First-class models can help users explore different scenarios and questions in their data without disconnecting from the main system. This makes it easier for them to test ideas and make smarter decisions.
  2. Allowing users to create branches of their data and modify them without changing the original provides a better way to investigate what-ifs and see the effects of potential changes. It combines version control with rich computational support.
  3. By enhancing how users interact with their data, we can improve productivity and decision-making in business. This change shifts the relationship between users and their systems, making data exploration a natural part of the process.

#40: "GenAI as the Sidecar" Strategy

OSS.fund Newsletter • 0 implied HN points • 11 Dec 25
🕹 Technology Systems Architecture
  1. Keep a deterministic "spine" that owns final decisions, accountability, and traceability, and treat GenAI as a sidecar that proposes or drafts but never makes binding choices.
  2. If an action creates legal obligations, liabilities, or regulated communications, the spine must execute it; tasks that involve reading, summarizing, drafting, or routing can live in the sidecar under supervision.
  3. Make evaluation continuous: use pre-deployment tests, shadow mode, production monitoring for drift and errors, and strict change control with versioning and rollback to keep the system safe.