Scenario / Work that can wait

Guided System Design Lesson: Queues and Workers

A write-heavy app tries to do every email and receipt while the user waits.

Run this scenario

Briefing

Queues and workers

Queues absorb bursts by letting non-urgent work wait; workers are what actually do it.

Queues absorb bursts by letting non-urgent work wait; workers are what actually do it.

Queues absorb bursts by letting non-urgent work wait; workers are what actually do it.

  • Watch queue depth in the simulator.
  • Watch workers in the simulator.
  • Watch async work in the simulator.

Contract

Uptime

95%

P95 latency

260ms

Budget

$700/mo

Traffic shape

Flash-sale surge with a steep ramp and sustained peak. Baseline 150 users; peak around 2,500 users over 30 hours.

Available components

Server

HTTP request handler Every web app needs at least one server. More servers let you handle more simultaneous requests before latency starts climbing.

Postgres

Primary data store Without a database, your app has no memory. Most dynamic requests eventually depend on it.

LB

Load balancer If you run more than one server, something needs to decide where each request goes. That is the load balancer.

Redis

In-memory cache layer Popular pages, profiles, and product data often get requested again and again. Serving those from memory is much faster and cheaper.

Replica

Read-only DB copy Many applications read far more often than they write. Replicas let you spread those reads across more machines.

Queue

Async job buffer Moving background work out of the request path keeps the app responsive even when extra processing is needed.

Worker

Background job processor Separating background work keeps checkout, page loads, and other user actions from competing with batch processing.

Common mistakes

  • Adding capacity after the bottleneck has already saturated.

Interview adjacency

  • Design background jobs
  • Explain async processing
  • Handle write-heavy traffic