← BACK TO DRAWING SET
SPECIFICATION · CONCEPT BRIEFDWG · 06-ASYNC-WRITES

Async Writes

Not every write needs the database to confirm before you reply.

§01Sync vs async writes

⚑ NOTE
Synchronous write
Server receives request → writes to DB → waits for confirmation → responds to client. Strong durability guarantee, but the client waits for the slowest hop.
⚑ NOTE
Asynchronous write
Server receives request → enqueues the write → responds to client immediately. A consumer drains the queue into the DB in the background. Fast acknowledgement, eventual durability.

§02When async is the right call

  • The client doesn't need the persisted result — just confirmation that the write was accepted (e.g., "like" buttons, analytics events, notifications).
  • You can tolerate a small window where the write is in the queue but not yet in the DB.
  • Bursty write traffic that would otherwise overwhelm the DB.
⚑ CAUTION
Trade-offs
If the consumer or queue crashes before draining, those writes are lost (in real systems, durable queues mitigate this). The DB becomes "eventually consistent" with what the client was told.
⚑ CHEATSHEET · QUICK REFERENCE
  • Client → LB → servers → queue → database.
  • Acknowledge fast; persist eventually.
  • Use sync writes when the client needs to read its own write back immediately.
▸ THE EXERCISE

Writes don't need a synchronous round-trip to the database — load-balance multiple servers, accept the request, queue the work, and let the database drain at its own pace. Acknowledge fast, persist eventually.

▸ START EXERCISEBACK TO DRAWING SET