Stateful vs Stateless Design
Stateless services do not store client state between requests — each request is independent.
The Tradeoff
Stateless services do not store client state between requests — each request is independent. Stateful services maintain state across requests (e.g., WebSocket connections, session data, in-memory caches).
Stateless: A Closer Look
No server-side state. All state is in the request or an external store (database, Redis).
The Good
- Easy to scale horizontally (any server can handle any request)
- Simple failover (no state to lose)
- Load balancing is straightforward
The Bad
- Every request must carry all needed context
- External state store adds latency
- Not suitable for real-time connections
Stateful: A Closer Look
Server maintains state between requests. WebSocket connections, in-memory caches, gaming sessions.
The Good
- Faster access to state (in memory)
- Natural for persistent connections
- Can maintain complex session logic
The Bad
- Hard to scale (sticky sessions needed)
- Failover loses state
- Load balancing is complex
Quick Comparison
| Stateless | Stateful | |
|---|---|---|
| Best for | REST APIs | WebSocket connections |
Real-World Examples
REST APIs are stateless by design — authentication is passed via tokens in every request.
WebSocket servers (Slack, Discord) are stateful — each server holds thousands of persistent connections.
Redis is a stateful service — it holds data in memory that would be lost on restart (solved with persistence).
Interview Advice
Default to stateless design in interviews — it is easier to scale. Use stateful only when the use case requires it (real-time features, caching). Always explain how you would handle failover for stateful components.
Source | System-Design-Overview
Practical Implementation for .NET Developers
In a .NET application, you would typically implement this pattern using the following approach:
ASP.NET Core setup: Create a service class that encapsulates the logic, register it with dependency injection, and inject it into your controllers or minimal API endpoints. The built-in DI container handles lifecycle management.
Entity Framework Core: For database interactions, EF Core provides the ORM layer. Use migrations for schema management and raw SQL for performance-critical queries. Consider Dapper for read-heavy paths where EF Core's overhead matters.
Azure integration: If deploying to Azure, leverage managed services — Azure Cache for Redis, Azure SQL, Azure Service Bus, Azure Cosmos DB. These eliminate operational overhead and provide built-in monitoring through Application Insights.
Testing: Use xUnit with Testcontainers for integration tests that spin up real databases in Docker. Mock external dependencies with NSubstitute. The WebApplicationFactory class lets you test your entire HTTP pipeline in-process.
Monitoring: Add Application Insights telemetry to track request latency, dependency calls, and custom metrics. Use structured logging with Serilog to make production debugging possible:
Log.Information("Processing order {OrderId} for {CustomerId}", orderId, customerId);
This gives you searchable, structured logs in Azure Monitor or Seq.
Real-World Decision Framework
A stateless service treats every request independently — it stores no session data between requests. A stateful service remembers information from previous interactions. This distinction is one of the most important architectural decisions in distributed systems.
When Stateless Wins
Stateless is the default for most web services because it enables horizontal scaling:
- REST APIs: Each request carries all necessary information (auth token, parameters). The server needs no memory of previous requests.
- Microservices: Each service instance is interchangeable. A load balancer can route any request to any instance.
- Serverless functions: AWS Lambda and Azure Functions are inherently stateless — they spin up, handle a request, and shut down.
- CDN edge nodes: Every CDN node can serve any request without knowing what the user did previously.
Benefits: Easy scaling (add more instances), simple deployment (no state to migrate), fault tolerance (any instance dies, others continue).
When Stateful Wins
Some workloads inherently require state:
- WebSocket connections: Chat servers maintain a persistent connection and track which user is connected to which server.
- Gaming servers: A multiplayer game server tracks player positions, health, and inventory in memory.
- Database connections: Connection pools maintain authenticated, reusable database connections.
- Shopping carts: Some e-commerce systems store cart state server-side for cross-device consistency.
- Workflow engines: Long-running business processes (order fulfillment, loan approval) track state across multiple steps.
Technologies: Actor frameworks (Akka, Orleans), stateful containers (Kubernetes StatefulSets), Redis for externalized state.
The Real Pattern: Externalize State
The industry best practice is to build stateless services that externalize their state to a shared store. Your application servers are stateless, but they read/write session data from Redis, user data from a database, and cache data from Memcached. This gives you the scalability of stateless with the functionality of stateful.
Interview Framework
- Can state live externally? Yes → stateless service + external store (Redis, DB). No → stateful.
- Do you need horizontal scaling? Yes → stateless. Limited scaling OK → stateful is simpler.
- Is the state temporary? Session data → externalize to Redis with TTL. Persistent data → database.
.NET Implementation
Stateless: ASP.NET Core with AddStackExchangeRedisCache() for distributed session. Stateful: Use Microsoft Orleans for virtual actor-based stateful services, or Dapr for state management in Kubernetes. Use IDistributedCache interface to abstract the state store.