Katkat
Back

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

AnyscaleSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Design a service that accepts JSON requests containing a target URL, a UTC timestamp and a payload, stores them durably, and sends each payload to its URL at the scheduled time. It tests finding due work at scale, delivery guarantees and retries, isolation from slow endpoints, outbound-request security and failure recovery.

Design a system that accepts JSON requests of the following form and, at the time given in timestamp, sends data to url:

{
 "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.

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?

Hints

Hint 1

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 2

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.

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?