Design WhatsApp Web Frontend
Designing a local-first web messaging app syncing state with mobile clients, decrypting media locally, and running offline databases.
1. Problem Statement
Design a secure, local-first web messaging client paired via QR codes, decrypting messages locally, and operating offline.
2. Business Context & User Friction
WhatsApp Web demands complete privacy and offline utility. Sluggish decryption delays or state desynchronization leads to immediately lost users.
3. Requirements Matrix
Functional Requirements
- Pair web app with mobile client using QR code tokens.
- Send and receive encrypted messages locally (Signal Protocol).
- Display messages checkmarks status indicators.
Non-Functional Requirements
Performance
- Local cryptographic decryption under 15ms.
- Zero-latency IndexedDB database queries.
- Smooth scroll feeds.
Scalability
- Support local databases sizes scaling to gigabytes.
- Decrypt messages inside background Web Workers.
Accessibility (a11y)
- Aria alerts for pairing states updates.
- Keyboard shortcuts for chat thread navigation.
Security
- Signal Protocol cryptography executed in sandboxed memory.
- Authorize QR link tokens securely.
Reliability & Failover
- 100% offline functionality using IndexedDB caches.
- Background data synchronization.
Observability
- Log decryption times.
- Track local database read latencies.
4. Core User Flows
Pairing and syncing messages
- User opens WhatsApp Web, displaying QR pairing code.
- User scans code with mobile client.
- Web app establishes WebSocket connection, fetching encrypted history.
- Web Worker decrypts messages, storing them in IndexedDB.
5. High-Level Design & Layers
The web app functions as a local-first interface, reading data from IndexedDB, decrypting payloads in Web Workers, and syncing via WebSocket pipelines.
Frontend Layers
- UI Layer: QRScannerPanel, ChatFrame, MessageRow.
- State/Security Layer: Cryptography Web Worker, IndexedDB store.
- Network Layer: Encrypted WebSocket sync client.
Major Components
- CryptoWorker: Decrypts payloads using Signal Protocol keys in background threads.
- QRConnector: Generates pairing tokens, matching WebSockets channels.
Data Flow Pipelines
- 1. Sockets pipe encrypted payload bytes.
- 2. CryptoWorker decrypts bytes into message objects.
- 3. Web app writes message objects to IndexedDB.
- 4. View hydrates directly from local IndexedDB stores.
6. Component Architecture & State Boundaries
| Component | Responsibility | State Owned | Dependencies |
|---|---|---|---|
| LocalAppShell | Coordinates QR connectors, database interfaces, and decryptions. | Pairing state, chats index | CryptoWorker, QRConnector |
7. State Management
Local UI State
- Active input composer strings
- Pairing codes
Server Query Cache State
Global/Shared State
- Active selected chat ID
- Decrypted keys specs
Real-Time & Sync State
- Encrypted messages synchronization stream
8. API Contracts Design
Purpose: Download QR code credentials.
{
"token": "qr123xyz",
"expiresIn": 60
}9. Caching Strategy
Browser/HTTP Cache
- IndexedDB as primary storage.
- Service worker caches app shell assets.
Edge CDN Caching
- Static assets caching on CDNs.
Application Cache
- Cache decrypted keys in browser memory.
Invalidation Policies
- Clear local databases on user logout.
10. System Strategies Checklist
Performance Strategy & Budgets
- Run cryptographical decryptions inside Web Workers.
- Recycle message list rows.
- Throttle WebSocket synchronization events.
Inclusive Accessibility Design
- Aria-live announcements on pairing success.
- Accessible close buttons inside overlays.
Security Safeguards & Risks
- Web Cryptography API encrypts message data.
- Authorize QR codes via signed WebSocket channels.
Telemetry & Production Observability
- Track decryption latency metrics.
- Log IndexedDB write failures.
Graceful Failure & Resilience
- Queue pending messages locally; sync once connection recovers.
- Redirect to QR pairing screen on token expiry.
Deployment, Rollout & CDN topologies
- PWA cached bundle running off local client files.
11. Architectural Decisions & Tradeoffs
Decision: Client-side decryption in Web Workers vs server-side decryption
Guarantees absolute end-to-end privacy and offline compatibility.
Throttles performance on older mobile browsers.
12. Interview Answer Framework
How to structure your defense of this architecture during a 45-minute technical system design session:
Define the local-first structure. Explain how QR pairing keys are established, and how encryption keys are managed on the web client.
- Do we need support for offline decryption?
- Are media attachments decrypted locally?
Detail a LocalAppShell containing CryptoWorker, IndexedDB interfaces, and WebSocket synchronization managers.
- Discuss Web Cryptography API and Signal Protocol.
- Explain IndexedDB performance tuning.
Conclude by evaluating security and performance compromises.
13. Common Pitfalls & Extension Questions
Candidate Mistakes to Avoid
- Running heavy decryptions on the main thread, causing typing lags.
- Not handling IndexedDB size limit overflows.
Interviewer Follow-ups / Extensions
- How do you handle audio attachments decryption without causing UI stutters?
- How do you synchronize chat read status across multiple concurrent browser tabs?