Katkat
Back

Design a ChatGPT-like web chat UI

OpenAISoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

This problem evaluates your ability to design a performant, scalable front-end architecture for a real-time conversational AI interface, focusing on state management, streaming data handling, and network resilience.

Problem Statement

Design the architecture for a web-based chat interface similar to ChatGPT. The application must support real-time token streaming, rich-text markdown rendering, conversation history persistence, and multi-modal message support (e.g., images, code snippets).

Functional Requirements

  1. Message Streaming: As the model generates text, the UI must update in real-time without blocking the main thread.
  2. Conversation History: Users should be able to scroll through long histories; the UI must support efficient virtualization.
  3. Formatting: Support Markdown rendering, syntax highlighting for code, and LaTeX-style math notation.
  4. Interactivity: Users can edit previous prompts, regenerating responses, or copy message content to the clipboard.

Non-Functional Requirements

  1. Latency: Minimize the time from the first token arrival to its display on the screen.
  2. State Management: Maintain a consistent state between the local UI, server-side conversation history, and local browser storage.
  3. Network Resilience: Handle connection drops during streaming and provide mechanisms to resume or retry requests.

Deliverables

  • Provide a high-level architecture diagram or description of the front-end components.
  • Explain how you would manage the stream of incoming tokens into the application state.
  • Define the data model for a 'Conversation' object and a 'Message' object.
  • Detail your strategy for rendering performance with very long chat logs.

Hints

Hint 1

Consider using an abstraction layer between the WebSocket or Server-Sent Events (SSE) source and your state management store.

Hint 2

Think about how to handle partial updates to the DOM without re-rendering the entire conversation history on every incoming token.

Hint 3

Evaluate the trade-offs between using a client-side state store like Redux/Zustand versus local browser caching strategies (e.g., IndexedDB) for offline capabilities.

Follow-up questions

  • How would you optimize the rendering process if the user is scrolling back through a conversation while new tokens are still being appended to the end?
  • What security considerations should be prioritized when rendering markdown content provided by an LLM to prevent XSS attacks?
  • How would you handle the 'regenerate' feature in terms of API design and UI state consistency if the model produces different outputs for the same prompt?