Design the Frontend of an AI Chat Application With Streaming Replies

In this system design round for a senior frontend role, you are asked to design an AI chat application with the focus on the frontend. A user writes a message, the model's reply appears in the conversation, and the user can continue the conversation or come back to earlier ones. Design the client: its component structure, state, communication with the backend, and how it behaves under slow responses, failures and long conversations. Describe the API contract the frontend needs from the backend, but you do not need to design the model serving itself. ```hint Replies take a while Think about what the user should see during the seconds between sending a message and the reply being complete, and what they may want to do meanwhile. ``` ```hint The reply is untrusted text Consider what the reply may contain once it is rendered as rich text. ``` ### Clarifying Questions - Should replies stream in as they are generated, or appear all at once? - Which platforms: desktop web only, or mobile web and native apps too? - Is there a history of multiple conversations, and must it sync across devices and tabs? - What can a reply contain: formatted text, code blocks, tables, images? Can users attach files? - Can the user stop a reply, regenerate it, or edit an earlier message? - How long can a conversation get, and are there usage limits the UI must communicate? ### What a Strong Answer Covers - Component breakdown: conversation list, message list, message rendering, composer - A client state model for conversations and messages, including per-message status (sending, streaming, complete, failed, stopped) - The streaming transport and how partial tokens are appended efficiently without re-rendering the whole conversation - Stop, retry and regenerate behavior, and optimistic display of the user's message - Safe rendering of model output (sanitized Markdown, code highlighting) and protection against script injection - Performance for long conversations (virtualization, pagination of history) and for fast token streams - Accessibility of streamed content and keyboard use - The API contract with the backend and handling of errors such as rate limits and disconnects ### Follow-up Questions - The user edits a message from earlier in the conversation. How do you model the resulting branches in state and in the UI? - The same conversation is open in two tabs. How do you keep them consistent? - How would you measure perceived responsiveness, for example time until the first words of a reply appear? - The network drops in the middle of a long reply. What does the user see, and what happens when the connection returns?