Why this matters
Stateless services let you scale horizontally, deploy safely, and recover quickly. In a Backend Engineer role, you will:
- Add instances behind a load balancer without losing user sessions.
- Do rolling or blue/green deployments without downtime.
- Autoscale workers to handle spikes and reduce cost when idle.
- Recover from instance failure without manual intervention.
Concept explained simply
A service is stateless when it does not rely on in-memory or local-disk state across requests. Each request is complete by itself, and any needed state lives outside the process (database, cache, queue, object storage, or the client).
Mental model
Think of each instance as a disposable kiosk: it reads inputs, performs work, and writes results to shared storage. If a kiosk disappears, others continue seamlessly.
Core principles (open to view)
- Request completeness: Every request carries all information needed or can fetch it from shared stores.
- No server-side sessions: Avoid per-user memory or local disk. Prefer tokens or shared session stores over sticky sessions.
- Externalize state: Use databases, caches (e.g., Redis), message queues, and object storage for persistence and sharing.
- Idempotency: Replays shouldn’t break things. Support idempotency keys or safe retries.
- Graceful lifecycle: Support quick start, health checks, and graceful shutdown so any instance can be replaced anytime.
- Deterministic behavior: Configuration via environment; no hidden local files or time-based implicit state.
- Ephemeral compute, durable data: Treat instances as cattle, not pets. Data lives off-instance.
Worked examples
1) Login sessions without sticky sessions
- Old pattern: Server stores sessions in memory. Users must stick to the same instance or get logged out.
- Stateless pattern: Issue signed access tokens (short TTL) and refresh tokens. Validate access tokens on any instance. Keep a shared revocation list (e.g., Redis) keyed by token ID or refresh token family for logout/compromise.
What happens on deploy?
New instances start and serve traffic immediately. No session migration needed. Old instances can be terminated without logging users out.
2) Image thumbnailing pipeline
- Upload API streams file to object storage and creates a job in a queue.
- Workers consume jobs, read from storage, generate thumbnails, and write back to storage. Metadata saved to a DB.
- Workers are stateless: no local disk reliance and safe to scale up/down.
Failure handling
- If a worker dies mid-task, another worker can safely retry because inputs/outputs live in shared storage.
- Use idempotent object keys (e.g., content-hash) to avoid duplicates.
3) Shopping cart API without in-memory state
- Client receives a cart_id cookie. Cart data stored in Redis or a DB.
- Add-item endpoint reads cart by cart_id, updates, and saves back.
- Any instance can handle any cart because state is externalized.
Idempotent add-item
Require an idempotency key per client request. Store processed keys with results for a limited time. If the same key reappears, return the stored result instead of creating duplicate items.
Who this is for
- Backend engineers building APIs, workers, or microservices that must scale and deploy frequently.
- Developers migrating from monoliths with server sessions or local state.
Prerequisites
- Basic HTTP and REST knowledge.
- Familiarity with databases and caches.
- Comfort with environment-based configuration and 12-factor ideas.
How to apply the principles
- Identify state: list everything your service keeps in memory or on local disk between requests.
- Externalize it: move state to a database, shared cache, object storage, or encode in client tokens.
- Make retries safe: add idempotency keys or use upserts/unique constraints for create operations.
- Harden lifecycle: implement health checks, readiness, and graceful shutdown (finish in-flight work before exiting).
- Test disposability: kill an instance during load; confirm no user-visible errors and zero lost progress.
Checklist
- No user session stored in process memory.
- No files written to local disk that must exist after restarts.
- Idempotent create endpoints with idempotency keys or unique constraints.
- Reads and writes go to shared stores (DB/cache/queue/object storage).
- Health checks and graceful shutdown implemented.
Common mistakes and self-check
- Sticky sessions: forces users to the same instance; breaks on scale or deploy. Self-check: remove stickiness in your load balancer and verify users stay logged in.
- Local disk reliance: temp files assumed to persist. Self-check: redeploy and confirm files are still available from shared storage.
- Non-idempotent POSTs: duplicate charges or orders. Self-check: replay the same request and confirm only one record exists.
- Warm in-memory caches as a requirement: instances need “warming” to work. Self-check: start a new instance and ensure correct behavior even with empty cache.
- Hidden time-based state: logic depends on instance uptime. Self-check: restart and verify identical results.
Exercises
Do these in any language or stack. Mirror of the Exercises section below.
Exercise 1: Convert session-based auth to stateless
Implement stateless auth using access tokens (short TTL) and refresh tokens. Include logout via a shared revocation list and rotation on refresh.
- Input: login(email, password)
- Output: access_token, refresh_token
- Capabilities: refresh, logout, token validation on any instance
Exercise 2: Idempotent order creation
Create POST /orders that accepts an Idempotency-Key header. Replaying the same key must return the same order without creating duplicates.
Exercise 3: Stateless image processing
Build an upload endpoint that stores files in object storage, enqueues a job, and a worker that creates a thumbnail and writes it back. No local disk dependence.
Submission checklist
- Endpoints work after killing and restarting instances.
- Replaying requests does not duplicate effects.
- No in-memory sessions or local file reliance.
Practical projects
- Build a stateless rate-limited API using a shared cache for counters (fixed window or token bucket).
- Create a stateless webhook receiver that verifies signatures and uses idempotency keys to avoid duplicate processing.
- Implement a small microservice with health/readiness endpoints, graceful shutdown, and autoscaling-friendly behavior.
Learning path
- Before: HTTP fundamentals, REST, basic DB usage.
- Now: Stateless Services Principles (this lesson).
- Next: Idempotency patterns, distributed caching, message queues, reliability patterns (retries, backoff, circuit breakers).
Mini challenge
Design a stateless password reset flow that works across multiple instances:
- Generate reset links that expire and can be used from any instance.
- Prevent reuse of the same link.
- Show how you store and validate tokens without server sessions.
Hints
- Use signed tokens mapped to a DB record with status and TTL.
- Make the consume operation idempotent (update-if-unused).
Next steps
- Run a chaos test: terminate instances during traffic and confirm zero user disruption.
- Add idempotency to all create/update endpoints that may be retried.
- Proceed to the Quick Test below. Available to everyone; sign in to save your progress.