Distributed System

Many queues and event brokers provide at-least-once delivery: a message that has been accepted can be delivered again when acknowledgements are lost, consumers crash, visibility timeouts expire, or the broker retries after uncertain outcomes. Duplicates are therefore not exceptional. A robust consumer should assume that the same logical event can arrive more than once. Why duplicates happen Consider this sequence: a consumer receives an event; it updates the database successfully; the process crashes before acknowledging the message; the broker makes the message visible again; another consumer receives it. The broker cannot know that the database update happened. Redelivery is the safer choice.

A request that crosses several cloud services does not have one timeout. It has a chain of deadlines: client, edge proxy, application, database, and downstream APIs. When those limits are configured independently, an upstream service can give up while downstream work continues consuming connections and CPU for a response nobody will use. An end-to-end timeout budget gives the request one bounded lifetime and lets each hop consume part of it.