The Load-Bearing System: An Advanced Guide to System Design and Architecture

On a Friday night in March, a ticketing startup called Ovation sold 941 tickets to a 900-seat comedy club. Forty-one people arrived holding a valid QR code and no chair. The bug was four lines long: read the remaining count, check it, write a row. No lock, no constraint.

Those forty-one seats were not a scaling problem. They were a correctness problem that scale made visible, and telling those two apart is most of what senior system design actually is.

The Load-Bearing System follows Ovation across fifty-one chapters, from one box running one ASP.NET Core app to a sharded, multi-region platform selling a stadium tour in eleven countries. Every technique in the book arrives because Ovation hit a wall that made it necessary. Nothing is introduced because it was next in a list.

WHAT THE BOOK COVERS — the fifty topics a .NET architect is expected to have opinions about:

Monolith versus microservices, modular monoliths, clean architecture, vertical slices, DDD, bounded contexts, CQRS and event sourcing. REST, gRPC, GraphQL, API versioning, YARP gateways, BFFs, service discovery, RabbitMQ and Kafka. Event-driven architecture, pub/sub, the outbox pattern, sagas, idempotency, MassTransit and Wolverine. Database per service, SQL versus NoSQL, eventual consistency, distributed transactions, sharding, read replicas, optimistic and pessimistic concurrency. Caching, Redis, rate limiting, load balancing, circuit breakers, retry and backoff, bulkheads, timeouts, health checks, graceful degradation. Horizontal scaling, stateless services, Docker, Kubernetes, Aspire. Configuration and secrets, logs and metrics and traces, OpenTelemetry, distributed tracing, OAuth 2.1 and JWT, zero trust.

FORTY MEASURED BAKE-OFFS. At every fork, Ovation's engineers spike two or three options, run them under the same load, and write a one-page Decision Record: the context, the options, the numbers, the choice, and what would make them revisit it. Thirteen of those forty records conclude "don't." Microservices lose to the modular monolith. Event sourcing loses for the catalogue and wins for the access log. GraphQL loses on the public API and wins on the promoter dashboard. Kafka loses to RabbitMQ at 4,000 requests a second and only wins later, when the numbers change. A service mesh loses to a resilience library and one engineer's attention.

WRITTEN FOR .NET 10 AND C# 14. Polly v8 resilience pipelines, EF Core 10, Aspire 13, YARP 2, HybridCache, the built-in rate limiter, OpenTelemetry with ActivitySource and Meter. Including the parts of the ecosystem that changed recently and that most books have not caught up with, such as MassTransit v9's move to commercial licensing and what a team should do about it.

YOU WILL ALSO READ ABOUT THE FAILURES. The retry storm Ovation caused itself, where three retrying layers turned one user action into twenty-seven requests and 4,000 requests a second became 108,000. The readiness probe that checked the database, failed on all forty pods at once, and turned a ninety-second database blip into a total outage. The circuit breaker that opened at a 3% error rate and made a partial degradation complete. The health of a system is mostly the record of what it survived.

The last chapter goes back to the same 900-seat club, walks one purchase through the finished system, and then argues the other side: how much of this Ovation could have skipped, and what a two-person team should build instead.

This is a standalone sequel to The Growing System: Design Patterns, SOLID, and System Design in Modern .NET. You do not need to have read it.

WRITTEN FOR: .NET developers with three to ten years behind them who are comfortable with C#, EF Core and ASP.NET Core, and who now have to make decisions that are expensive to reverse.