System Design for .NET Backend Engineers

System design is a conversation, not a diagram contest

Backend engineers on .NET teams get asked to design services, not entire social networks—unless you are interviewing at hyperscale companies. We teach system design at Toolliyo as structured thinking: clarify requirements, propose a baseline, identify bottlenecks, evolve the design, and name trade-offs. Your interviewer wants to see how you would partner on a real project.

Framework for the first fifteen minutes

1. Functional requirements — what must the system do? User stories, APIs, workflows.
2. Non-functional requirements — latency, availability, consistency, scale, compliance.
3. Back-of-envelope estimates — requests per second, storage growth, bandwidth.
4. High-level components — clients, API gateway, services, data stores, async workers.
5. Deep dives — pick two areas the interviewer cares about: data model, cache, sharding, etc.

Ask questions before you draw boxes. "Do we need strong consistency on inventory decrements?" changes the design completely.

Sample prompt: order processing platform

Design an API where customers place orders, inventory is reserved, payment is captured, and fulfillment is notified. Walk through:

API layer (ASP.NET Core)

Stateless services behind a load balancer. JWT auth, idempotency keys on POST /orders so retries do not double-charge. Return 202 with tracking ID when async steps remain; expose GET /orders/{'{'}id{'}'}/status.

Data model

• Orders table (SQL) for transactional integrity.
• Order events table or outbox for reliable publishing.
• Read model or materialized view for order history UI if write schema differs from read needs (CQRS-lite).

Inventory and concurrency

Optimistic concurrency on stock rows or short Redis locks with TTL. Never oversell: database constraint on QuantityAvailable >= 0 as last line of defense. Discuss saga vs two-phase commit—most .NET microservices use sagas with compensating transactions.

Async processing

Publish OrderPlaced to Azure Service Bus or RabbitMQ. Worker services on .NET process payment, emit PaymentCaptured or compensating ReleaseInventory. Use dead-letter queues and poison message handling you can describe operationally.

Caching strategy

Cache product catalog reads in Redis with TTL and version stamps. Do not cache personalized cart data globally. Explain cache-aside vs read-through and how you invalidate when prices change—event-driven invalidation beats blind short TTL alone.

Reliability patterns

• Retries with jitter — Polly policies in HTTP clients; cap attempts.
• Circuit breakers — fail fast when payment provider is down; queue orders for later if business allows.
• Health checks — readiness excludes instance from load balancer when SQL unreachable.
• Graceful degradation — show catalog without recommendations if ML service fails.

Observability from day one

Structured logging with correlation IDs across API and workers. Metrics: request rate, error rate, duration (RED). Traces across HTTP and message handlers with OpenTelemetry—Application Insights or Grafana stack. Alerts on SLO burn, not only CPU.

Scaling axes

Vertical scale first on App Service or containers; horizontal scale stateless API tier; read replicas for reporting; partition orders by tenant or region when single SQL database saturates. Sharding is a last resort—mention it, show you understand cost.

Security and compliance

Encrypt data at rest, TLS in transit, secrets in Key Vault, least-privilege managed identities, audit log for admin actions. PCI scope reduction: tokenize payments with Stripe/Adyen instead of touching card numbers.

Common interview mistakes

1. Jumping to Kubernetes before explaining a monolith might suffice for years.
2. Ignoring idempotency and duplicate delivery in messaging.
3. Choosing MongoDB or Cassandra without a access-pattern reason.
4. Forgetting operational concerns: deployments, migrations, on-call.

Practice exercises

• URL shortener with analytics.
• Rate-limited public API for partners.
• Notification service (email, SMS, push) with preferences and retries.
• File upload and virus scan pipeline with blob storage.

Time yourself: forty-five minutes whiteboard or Excalidraw, then five-minute verbal summary as if presenting to a product manager and tech lead.

Mapping design to .NET implementation

Name concrete tools: ASP.NET Core minimal APIs or controllers, EF Core vs Dapper, Hangfire or Azure Functions for background jobs, YARP as reverse proxy, MassTransit for messaging abstractions. Interviewers trust candidates who connect boxes to libraries they have used.

System design skill compounds with every production incident you survive. Study patterns, practice aloud, and tie each decision to a user-visible outcome—latency, correctness, or cost. That is how .NET backend engineers grow from "implements tickets" to "owns services."