Designing an asynchronous messaging service: API, delivery guarantees, failures

You are a product manager at Amazon. Design a web service that lets parties communicate asynchronously: a sender hands a message to the service now, and the receiver picks it up and handles it later, even if the receiver was busy or offline when it was sent. Explain how it works and what you would build first. ```hint Follow one message Trace a single message from the moment the sender hands it over until the receiver has finished with it, and ask what happens if the sender, the receiver or a server fails at each step. ``` ### Clarifying Questions - Are the senders and receivers software systems handing work to each other, or people messaging each other? - Is it acceptable for a receiver to occasionally get the same message twice, and does the order of messages matter? - Should each message go to exactly one receiver, or to every subscriber interested in it? - Is this an internal platform for Amazon's own teams or a product sold to outside developers? ### What a Strong Answer Covers - A clear scope: who sends, who receives, and delivery and ordering guarantees chosen on purpose - An API for sending, receiving and acknowledging, and how unacknowledged messages are retried and failing ones set aside - Storage, replication and partitioning that keep accepted messages durable while throughput grows - Failure modes (crashed receivers, duplicate sends, messages that always fail, a data center outage) and the metrics that reveal a growing backlog - A product view: target customers, a first release versus later features, and how success would be judged ### Follow-up Questions - How would you guarantee order for messages that belong to the same customer order, and what does that cost in throughput? - A consumer team reports that some orders are processed twice. What would you change in the service, and what would you ask that team to change? - How would you price the service for outside developers?