Design a Service That Sends a JSON Payload to a URL at a Scheduled Time

Design a system that accepts JSON requests of the following form and, at the time given in `timestamp`, sends `data` to `url`: ```json { "url": "https://example.com/api", "timestamp": "2026-07-05T12:30:00Z", "data": { "...": "..." } } ``` A client submits the request ahead of time. The service stores it and makes the outbound request to `url` when the scheduled time arrives. Cover the API for submitting requests, how scheduled requests are stored, how the system finds the requests that are due and delivers them on time, and what happens when a delivery fails or a component crashes. ```hint Finding what is due Scanning every stored request once a second does not scale. Think about how to organize requests by due time so that each worker touches only what is about to fire, and how two workers avoid sending the same request. ``` ```hint The crash between sending and recording Picture a worker that sends the request and dies before it records success. Decide which delivery guarantee the service can honestly offer, and what the receiver needs in order to cope with it. ``` ### Constraints and Clarifications - Given: each request carries a target URL, an ISO 8601 UTC timestamp and an arbitrary JSON payload, and the service must deliver the payload to the URL at that time. - Not given: the HTTP method and headers of the outbound call, request volume, how far ahead requests are scheduled, how close to the timestamp delivery must happen, payload size limits, retry expectations, and whether clients can cancel or look up a request. Ask, or state your assumptions. ### Clarifying Questions - What does "send" mean: an HTTP POST with `data` as the JSON body? With which headers and timeout? - How precise must delivery be (within a second, a few seconds, a minute), and is early delivery ever acceptable? - What should happen to a timestamp in the past, or to one years in the future? - What counts as a successful delivery, and how long should the service keep retrying a failing target? - How many requests are submitted and delivered per second at peak, and do many of them share the same timestamp? - Do clients need to cancel, update or look up a scheduled request, or be told when a delivery finally fails? - Who are the callers, and may they target any URL on the internet? ### What a Strong Answer Covers - Settles the outbound method, timing precision, delivery guarantee, retry policy and scale before designing - A durable submission API with idempotent creation and a clear lifecycle for each request - An efficient way to find due requests, partitioned so that many workers share the load without double claiming - An honest delivery guarantee that receivers can deduplicate, plus retries with backoff and a final failure path - Isolation from slow or failing targets, and protection against the service being used to reach internal addresses - Failure handling for workers, the store and clocks, and metrics for delivery lag ### Follow-up Questions - A million requests are scheduled for exactly midnight UTC. How does your design keep delivery lag bounded? - One target endpoint becomes slow and starts timing out. How do you stop it from delaying deliveries to every other target? - A client cancels a request one second before its scheduled time. Can you guarantee that it will not be sent? - How would receivers verify that a request really came from your service and is not a replay?