Design a Public API for Hundreds of Daily External Users

Design a public API that hundreds of external users will use every day. The API's business domain is intentionally unspecified. Explain the requirements you would establish and the interface and operational decisions needed to make it usable and reliable. ### Constraints & Assumptions - Do not invent a business resource or workflow and present it as a requirement. - Hundreds of daily users do not determine peak request rate, payload size, or cost per request. - External clients need a stable contract and a way to diagnose errors. ### Clarifying Questions to Ask - What tasks should the API support, and which operations read or change data? - Who are the clients, how are they authenticated, and what data may each access? - What are the expected bursts, response sizes, latency needs, and availability expectations? ```hint A public API is a long-lived contract. Consider what a client needs to do safely when a request times out or an API version changes. ``` ### What a Strong Answer Covers Explain resource and operation design after clarifying the domain, then cover authorization, validation, pagination, errors, retries, rate limits, documentation, compatibility, and observability. Scale the architecture to actual traffic and risk rather than inferring a large distributed system from a user count alone. ### Follow-up Questions - How would clients safely retry a state-changing request? - How would you introduce a breaking change? - Which signals would reveal that clients are struggling even if the server is healthy?