System Design .NET A -> Z: What This Series Teaches

You can write clean C# for ten years and still freeze when somebody asks "how would you build Twitter". Not because the problem is hard, but because system design is a different skill from writing code. The skill is choosing — which database, which cache, which queue, which failure to absorb and which to reject. This series teaches that choosing in twenty-six chapters, every one ending in a working .NET 10 implementation rather than a whiteboard diagram.

What is system design and why does it matter for .NET engineers?

System design is what you do before the first commit on a new service: pick the data store, the communication style, the cache, the queue, the deployment shape. The choices you make here are the ones that get expensive to undo six months in. Switching a List<T> to a HashSet<T> is a 15-minute refactor; switching from PostgreSQL to Cassandra is a quarter.

For a .NET engineer specifically, the skill matters because the .NET ecosystem hides a lot of the design behind sensible defaults — EF Core gives you a relational database, ASP.NET Core gives you HTTP, MediatR gives you in-process messaging. Those defaults are correct most of the time. The chapters in this series are about the times they are not: when the read load demands a cache, when the write load demands a queue, when the consistency model demands an outbox.

How is system design different from design patterns?

Design patterns operate inside a single process. A Singleton, a Decorator, a Mediator — these are choices about classes and methods. System design operates between processes: one service talks to another over a network, one database shards across nodes, one queue buffers spikes between producers and consumers. The two skills layer.

flowchart TB
    subgraph SD["System design - between processes"]
        Svc[Service A] -->|HTTP / gRPC| SvcB[Service B]
        Svc --> Q[(Queue)]
        Svc --> Cache[(Cache)]
        Svc --> DB[(Database)]
    end
    subgraph DP["Design patterns - inside one process"]
        Ctrl[Controller] --> Med[Mediator]
        Med --> Hdl[Handler]
        Hdl --> Repo[Repository]
        Repo --> Dec[Decorator: Logging+Retry]
    end
    SD -.uses.-> DP

Inside Service A, you might use Mediator + Decorator + Repository. Between Service A and Service B, you choose REST vs gRPC, synchronous vs queue, strong vs eventual consistency. Both layers exist in every real .NET application; this series fills the gap above the design-patterns layer.

What are the seven questions every chapter answers?

The series uses one consistent shape so you can skim a chapter in sixty seconds. Every article walks through these seven questions:

1. When does this problem actually show up? — the symptom in production, not the textbook definition.
2. What are the back-of-envelope numbers? — QPS, storage, bandwidth, latency budget. Concrete numbers, not "lots".
3. What does the minimal single-node architecture look like? — the simplest thing that works, before any scale.
4. What is the scale-out variant and what does it cost? — the trade-off table that gets argued about in interviews.
5. What is the .NET 10 implementation? — the library, the Program.cs wiring, the EF Core / Redis / RabbitMQ code.
6. What are the failure modes and how do you observe them? — what breaks first and the metric that catches it.
7. When should you not use this? — the over-engineering smell, the case where the simple thing was right.

H2 headings end with ? because that is what AI engines and search engines pattern-match on for "answer" cards. The format is also a discipline — if you can't phrase the section as a question, the section probably says nothing.

Which problems will this series teach you to solve?

The twenty-six chapters split into six groups. Read the group entries to see what each chapter tackles:

• Foundations (3) — scalability vocabulary, back-of-envelope arithmetic, CAP and consistency models. These appear in every other chapter.
• Building blocks (6) — the .NET-specific tools you reach for: Redis caching, SQL vs NoSQL, message queues, REST vs gRPC vs GraphQL, Elasticsearch integration, and JWT vs cookie auth.
• Reliability (3) — idempotency and the outbox pattern, circuit breakers with Polly, and sagas for distributed transactions.
• Observability and ops (2) — OpenTelemetry in .NET and rate limiting with the built-in middleware.
• Case studies (9) — end-to-end designs for URL shortener, rate limiter, news feed, realtime chat, notification system, file upload, typeahead autocomplete, payment checkout, and analytics events pipeline.
• Wrap-up (2) — how to answer system design interviews and a series conclusion with the lessons that survive every chapter.

The case studies are the chapters most likely to appear word-for-word in a system design interview. They are written so you can use them both ways: read the architecture for the interview, read the .NET section for the production project on Monday.

How should I read this series — by problem, or in order?

Two reading paths, both valid.

By problem — open the chapter that names the symptom you have right now. If the cache invalidation is killing you, go straight to caching. If a stripe webhook keeps double-charging customers, go to idempotency. Each chapter is self-contained and links forward and backward to the chapters whose ideas it depends on.

In order — read 00 through 25. The order is deliberate: foundations first because every later chapter quotes their numbers, building blocks next because the case studies compose them, then the case studies as the integration tests of everything before. The full sequence takes about a week of evenings; the reward is recognising the same components reused in nine different contexts.

// Example of a building block reused across case studies:
// AddRedisCaching wires the same IDistributedCache used by
// the URL shortener, the rate limiter, and the news feed.
builder.Services.AddStackExchangeRedisCache(opt =>
{
    opt.Configuration = builder.Configuration.GetConnectionString("Redis");
    opt.InstanceName  = "anhtu-dev:";
});

The same five-line registration shows up in three case-study chapters. That is the point — the series is teaching you a small alphabet, then showing nine different sentences you can spell with it.

What .NET 10 ecosystem assumptions does the series make?

Every chapter assumes the same baseline so you can copy code between chapters without conversion. The stack is:

• .NET 10 with ASP.NET Core, minimal APIs by default, Razor or controllers when the chapter needs them.
• EF Core 10 for relational data, with PostgreSQL as the reference database (the SQL syntax is generic enough to work on SQL Server or MySQL).
• StackExchange.Redis wrapped through IDistributedCache for caching.
• MassTransit over RabbitMQ for queues; Azure Service Bus appears when the chapter is specifically about cloud-managed queues.
• Polly for retries and circuit breakers, increasingly via the built-in Microsoft.Extensions.Http.Resilience.
• OpenTelemetry for traces, metrics, and logs; Serilog for the log sink, Prometheus or Azure Monitor for metrics.
• MediatR when the chapter needs in-process pub-sub; otherwise plain DI.

The chapters do not assume any specific cloud. Where Azure-specific tools (Service Bus, Cosmos DB) are useful, AWS or self-hosted alternatives are also given.

Where should you start tomorrow?

If you have ten minutes, read scale vocabulary — it is the dictionary every later chapter speaks. If you have an hour, read it plus back-of-envelope and pick one case study that matches a project you are working on. If you have a week, read 00 through 14 — that gets you through every building block and reliability pattern, and case studies become much faster after that.

The series is not a textbook to finish; it is a reference to keep open. The patterns will appear in your code reviews, your interviews, and your incident retrospectives. Knowing the names lets you describe your design in one paragraph instead of five files of source code.

Welcome aboard.