Evolve a Polling Chat API for Production

Evolve a basic chat API into a system suitable for high concurrency, real-time communication, and durable message storage. The starting interface is: - `GET /messages`: clients poll every 10 seconds. The response is an array of objects containing `text`, `userId`, and `timestamp`. - `POST /messages`: the request contains `text` and `username`; the response is empty. Clarify the conversation and access model, then explain the changes you would make to the API and architecture. Any new fields or operations are your proposed design, not features supplied by the starting interface. ### Part 1 — Repair the API contract How should messages be identified, attributed, acknowledged, and retrieved? #### What This Part Should Cover - Authenticated identity and authorization to read or write a conversation. - Message identifiers, retry behavior, ordering, and bounded history retrieval. ### Part 2 — Add real-time delivery How would you improve on ten-second polling while supporting reconnects and slow clients? #### What This Part Should Cover - A justified transport choice and connection management. - Catch-up behavior that does not lose messages between history and live delivery. ### Part 3 — Scale and persist the system Explain the write, storage, and fan-out paths, including failure recovery. #### What This Part Should Cover - The meaning of a successful send acknowledgement. - Partitioning, durable publication, duplicate delivery, and operational limits. ### What a Strong Answer Covers - An end-to-end path from authorized submission to durable storage and delivery. - Explicit guarantees instead of treating a live connection as reliable message storage. - A migration path from the original polling API. ### Follow-up Questions - What happens if the message is committed but the sender times out before receiving the acknowledgement? - How does a reconnecting client avoid a gap between its history response and its live subscription?