📮 Pub/Sub vs Queues: Picking the Right Primitive
One message, many readers, or one message, one reader — sounds like a trivial choice until you build the wrong one and spend a sprint bolting the other behavior on top.
8 articles tagged with "messaging"
One message, many readers, or one message, one reader — sounds like a trivial choice until you build the wrong one and spend a sprint bolting the other behavior on top.
Your producer is fast, your consumer is slow, and nobody told the pipe in between. Here's how backpressure keeps async systems from eating themselves alive.
Your database commit succeeded. Your Kafka publish failed. Now what? The transactional outbox pattern fixes the dual-write problem that every 'just publish an event after saving' tutorial conveniently skips.
Everyone reaches for \"a message broker\" like it's one thing. It isn't. Queues and pub/sub solve different problems, and picking the wrong one doesn't fail loudly — it just quietly rots your architecture for the next two years.
Exactly-once delivery is the Bigfoot of distributed systems: everyone's heard of it, nobody's actually seen it in the wild. Here's what your message queue is really promising you, and how to stop getting burned by the gap.
Most teams wire up a dead letter queue, feel very responsible, and then never look at it again. Here's how to build one that actually gets messages back to life instead of just being a fancier trash can.
You write to the database, then publish an event. What happens when the process dies between those two lines? The outbox pattern is the boring, reliable answer to a problem every event-driven system eventually hits.
Distributed transactions are where microservices go to cry. The saga pattern gives you eventual consistency without locking every service in a two-phase commit death grip — here's how it actually works.