Design a desktop AI chat frontend

Q: Design a desktop AI chat frontend

This question evaluates frontend architecture and system-design competencies, including cross-platform desktop app design, state management and persistence, token-streaming UI, performance engineering, security boundaries and sandboxing, observability, build/deployment, testing, accessibility, and extensibility.

Q: How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

Q: What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Technical Screen rounds at Anthropic.

Q: What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Anthropic during technical interviews.

Question

Design a Frontend Architecture for a Cross-Platform Desktop Conversational AI App

Context

You are designing the frontend architecture for a cross-platform desktop conversational AI application — think of a Claude-style desktop client. The app runs on macOS, Windows, and Linux using a web technology stack (e.g., Electron, Tauri, or a native WebView shell), with the UI talking to a remote model API over a streaming connection.

The app must support token-streaming chat, file attachments, multiple concurrent chats/workspaces, and multi-window usage, while treating security, performance, and extensibility as first-class concerns.

Walk through your architecture end to end, calling out the key design decisions and trade-offs along the way.

Constraints & Assumptions

Unless you choose to renegotiate them with the interviewer, anchor your design to the following:

Single user, multiple devices. One person signs in on more than one machine; there is no multi-tenant or team-collaboration requirement.
Remote model. Generation happens server-side; responses arrive as a token stream (assume SSE or WebSocket). The client never runs the model locally.
Conversation scale. A single chat can reach 100k+ tokens and thousands of messages ; a user may have hundreds of chats across workspaces.
Offline expectations. Offline reading of existing history is required; offline generation is not.
Sensitive data. Conversations contain private user content, so privacy and security are first-class, not afterthoughts.
This is a frontend / client architecture exercise — the focus is the desktop client and its boundary with the OS and the model API, not the backend model-serving infrastructure.

Clarifying Questions to Ask

A strong candidate scopes the problem before designing. Good questions to raise with the interviewer:

What is the target conversation size and chat count we must stay smooth at (e.g., 100k tokens, 5,000 messages, hundreds of chats)? This drives virtualization and memory strategy.
What is the streaming transport and token rate (SSE vs WebSocket; typical and burst tokens/second)? This drives the rendering and backpressure design.
Is end-to-end encryption for cloud sync a hard requirement, or is encryption-at-rest sufficient for v1?
How important is binary footprint / install size versus time-to-first-ship ? This is the crux of the Electron-vs-Tauri decision.
Must multiple windows view the same chat simultaneously (e.g., watch a response stream in a second window), and how live must that mirroring feel?
What plugin / extensibility surface do we need at launch versus later, and who authors plugins (first-party only, or third parties we must sandbox)?

What to cover

1. Core modules

Chat view with token streaming
File attachments and previews
Multi-chat workspaces and tabbed navigation
Multi-window support

2. State management & persistence

Session history and drafts
Offline-first data model
Encryption (end-to-end or at-rest)
Cloud sync with conflict resolution

3. Performance

Virtualized rendering for long conversations
Incremental rendering of streaming tokens
Use of Web Workers and OffscreenCanvas where helpful
Memory constraints and backpressure
Avoiding layout thrash

4. Security

IPC boundaries and sandboxing
Filesystem/network permission model
Secret handling and storage
Content sanitization
Update integrity and code signing

5. Observability

Telemetry and privacy-preserving analytics
Crash reporting and performance tracing

6. Build & deployment

Packaging across operating systems
Auto-updates and differential (delta) updates
Differential and lazy loading
Feature flags and rollback strategy

7. Testing

Unit, integration, and end-to-end (E2E)
Contract tests for IPC boundaries

8. Accessibility & i18n

9. Extensibility

Plugin system (capabilities/permissions)
Theming

10. Trade-offs

Compare the Electron , Tauri , and native WebView stacks, and recommend one.

Deliverables

A high-level component diagram
A high-level state / data-flow diagram
A discussion of the key design decisions and trade-offs behind your choices

What a Strong Answer Covers

The interviewer is listening for the dimensions below, not a recital of buzzwords. A strong answer:

States a clear renderer/host split up front and justifies which process owns the streaming hot path versus durability, with the latency/serialization trade-off made explicit.
Designs the streaming render path concretely — off-main-thread parsing, frame-coalesced updates, single-row re-render, and why per-token commits cause jank.
Handles scale with virtualization and gives a sense of the memory win, plus an eviction / warm-chat strategy and a named backpressure trigger.
Presents a coherent data model and persistence story — single-writer storage, offline-first reads, drafts that survive a crash, and a sync design that reasons about which data can actually conflict before picking a merge strategy.
Treats security as a layered model — untrusted renderer, schema-validated allow-listed IPC, a permission model for FS/network, keychain-backed secrets, sanitization of model output as a defense against prompt-injected Markdown, and signed/verified updates.
Covers the cross-window consistency problem — how durable changes fan out after commit versus how a live in-flight stream is mirrored, and why those are different channels.
Makes a defensible Electron/Tauri/native recommendation anchored in real trade-offs across the relevant axes (rendering engine, footprint, ecosystem, security, updater) and keeps it swappable behind a platform abstraction.
Doesn't skip the "boring" pillars — observability (privacy-preserving, opt-in), testing (IPC contract + deterministic streaming stub), a11y/i18n, and safe staged rollout with rollback.
Communicates with diagrams and prioritization — a clear component and data-flow diagram, and a sensible MVP-to-mature build order.

Follow-up Questions

Be ready for the interviewer to push deeper:

Two windows, same chat, one streaming response. How do you mirror a live in-flight stream to the second window without making the host process the bottleneck — and what does the observer window see if a frame drops?
A crash mid-stream. What exactly is lost, and how do you bound it? Walk through your persistence throttle and the finalize step.
What breaks first at 10x scale — 10x more messages per chat, or 10x token rate? Where does your design degrade, and what's the next mitigation?
Sync conflict in practice. Two devices rename the same chat offline, then reconnect. What does the user see, and which fields do you silently merge versus surface for resolution?

Design a desktop AI chat frontend

Quick Overview