MESSAGE QUEUES: Become the engineer trusted with the pipeline that never drops a payment or runs it twice, the one whose systems hold under load.
MESSAGE QUEUES: Become the engineer trusted with the pipeline that never drops a payment or runs it twice, the one whose systems hold under load. - Image 2

MESSAGE QUEUES: Become the engineer trusted with the pipeline that never drops a payment or runs it twice, the one whose systems hold under load.

$ 150.838,00

This book teaches you to build asynchronous, event-driven systems on queues and brokers that you can actually trust, instead of ones that lose work, double-process it, or fall over under load. It starts from why you reach for a queue at all (decoupling, buffering a spike, and doing slow work out of the request path) and the cost you take on: you have traded a simple synchronous call for a system with new failure modes. It builds the core model first, the producer, the broker, the consumer, and the one fact that explains most bugs: real brokers deliver at least once, not exactly once, so your handler must be idempotent or you will double-charge on the inevitable redelivery. It covers the guarantees in plain terms (ordering and why it is only per-partition or per-queue, acknowledgements and when a message is really done, durability and what survives a broker crash) and the patterns that keep a system honest: idempotent consumers, dead-letter queues for poison messages, retries with backoff, and the outbox pattern for publishing an event and committing a database change atomically. It places the main tools honestly (Kafka for a durable ordered log and event streaming, RabbitMQ for flexible routing, SQS for a managed queue, Celery for Python task queues) so you pick by the job. The back half is operating it: backpressure when producers outrun consumers, monitoring queue depth and consumer lag before it becomes an outage, and exactly-once processing as an effect you engineer, not a checkbox you tick. The examples are a real pipeline, shown losing and duplicating work and then made reliable. For backend engineers who want async systems that deliver every message exactly once in effect, even though the broker does not.

SKU: MESSAGE-QUEUES-EN Category: Tags: , , ,

Description

A customer emails you furious that you charged their card twice, and when you go hunting for the bug there is not one: your code was fine, the queue delivered the same message twice and your handler ran it both times. That is the hidden deal of a queue. It looks like the easy way to make a slow thing async, and it quietly changes every guarantee you had. The moment work goes through a broker, a message can be delivered twice, arrive out of order, sit in a queue for an hour, or vanish into a dead-letter nobody is watching, and a consumer that crashes mid-message can either lose the work or do it again. Most queue bugs are not the broker, they are the assumptions: code that assumes exactly-once delivery when the broker promises at-least-once, a handler that is not idempotent so a redelivery double-charges, no dead-letter queue so a poison message blocks the line forever, and no backpressure so a fast producer drowns a slow consumer. Using a queue well is knowing exactly what it does and does not guarantee, and building the handler that survives the redelivery, the reorder, and the crash.

This book teaches you to build asynchronous, event-driven systems on queues and brokers that you can actually trust, instead of ones that lose work, double-process it, or fall over under load. It starts from why you reach for a queue at all (decoupling, buffering a spike, and doing slow work out of the request path) and the cost you take on: you have traded a simple synchronous call for a system with new failure modes. It builds the core model first, the producer, the broker, the consumer, and the one fact that explains most bugs: real brokers deliver at least once, not exactly once, so your handler must be idempotent or you will double-charge on the inevitable redelivery. It covers the guarantees in plain terms (ordering and why it is only per-partition or per-queue, acknowledgements and when a message is really done, durability and what survives a broker crash) and the patterns that keep a system honest: idempotent consumers, dead-letter queues for poison messages, retries with backoff, and the outbox pattern for publishing an event and committing a database change atomically. It places the main tools honestly (Kafka for a durable ordered log and event streaming, RabbitMQ for flexible routing, SQS for a managed queue, Celery for Python task queues) so you pick by the job. The back half is operating it: backpressure when producers outrun consumers, monitoring queue depth and consumer lag before it becomes an outage, and exactly-once processing as an effect you engineer, not a checkbox you tick. The examples are a real pipeline, shown losing and duplicating work and then made reliable. For backend engineers who want async systems that deliver every message exactly once in effect, even though the broker does not.

Is this book for you?

This book is for: backend engineers wiring services together with queues and brokers (Kafka, RabbitMQ, SQS, Celery) who want delivery they can trust, instead of a system that silently drops messages, double-charges on a retry, or processes events out of order.

What makes this one different

The 6 Steps to Becoming the Engineer Trusted With the Money That Moves Through the System. The method for building async systems on queues that deliver every message exactly once in effect, even though the broker only ever promises at-least-once. Stop losing work, double-charging on a retry, and processing events out of order. Go from a pipeline that silently drops and duplicates messages to one you can finally trust under load.

  • Know the cost before you reach for a queue
  • Know the roles every bug lives on
  • Know the guarantees the broker really gives
  • Survive the redelivery, the poison, the flood
  • Close the gap between the commit and the event
  • Choose the broker and watch it under load

What you’ll get inside

  • Chapter 1: The double charge nobody wrote a bug for
  • Chapter 2: When a queue is worth it, and when it just adds risk
  • Chapter 3: The three roles behind every message
  • Chapter 4: Why the same message arrives twice, on purpose
  • Chapter 5: The order you send is not the order you get
  • Chapter 6: Charging a card once when the message comes twice
  • Chapter 7: The one bad message that can freeze your whole queue
  • Chapter 8: When a retry makes everything worse
  • Chapter 9: Saved to the database, lost before the broker
  • Chapter 10: Kafka, RabbitMQ, or SQS: which one your problem is asking for
  • Chapter 11: The metric that warns you 20 minutes before the outage
  • Chapter 12: Why exactly-once delivery is mostly a myth
  • Chapter 13: The async system you can finally trust

Related products