Architecture Note: When to pick SQS FIFO over a DB queue
A decision framework I use when the team reaches for a Postgres-backed queue by default.
Part of Backend Craft
Teams reach for "just use a table" queues more than they should. Sometimes that's right. Often it's a time bomb.
My decision tree:
- Is ordering per-key required? → SQS FIFO with MessageGroupId. A DB queue gets this right only if you're careful with
SELECT FOR UPDATE SKIP LOCKED. - Is throughput ever going to exceed a few hundred/sec? → SQS. DB queues fight with the rest of your app for connections and row locks.
- Is exactly-once needed at the consumer? → Neither gives you that. Design idempotent consumers; use SQS FIFO's dedup window as a safety net.
- Is the consumer outside the DB's blast radius? → SQS. Don't couple an external worker to your primary Postgres.
A DB queue is right when the work is intrinsically tied to a transaction — "after this row commits, do X." SQS is right when the work is extrinsic.
Related
Keep reading
Daily Note: TIL — Polly SSML <mark> tags
Polly's SSML <mark> tags emit timing events over the stream. Useful for synchronizing on-screen captions to voice playback.
Building Voice Integrations on Top of Async Chatbots
What breaks when you front an async chatbot with Amazon Connect + Lex, and how to keep latency, barge-in, and context handoff sane.
What I Learned Designing Omnichannel Backend Integrations
Shared intent schema, eventually-consistent conversation state, and why the channel should be the last thing your backend knows about.
Keep going
Where to next?
Browse more technical writing, see the engineering case studies, or reach out directly.