System Design Guide
advancedhigh Relevance13 min read
Design Slack/Microsoft Teams Frontend
Architecting a real-time messaging application managing heavy workspace channels, message streams, and local histories.
Architecture Focus:
Normalized local storesMessage list virtualizationOffline data synchronization
1. Problem Statement
Design a chat application managing multiple workspaces and channels, rendering heavy message lists, and maintaining local history.
2. Business Context & User Friction
Chat applications require fast transitions and immediate message echoes. Slow channel loads or lost messages lower user engagement.
3. Requirements Matrix
Functional Requirements
- List workspaces and channels lists.
- Real-time message feeds with threads, reactions, and file attachments.
- Display client presence markers (online, away, dnd).
Non-Functional Requirements
Performance
- Channel swapping transition times under 50ms.
- Under 2-second initial cold start page load.
- Zero layout shifts when loading message images.
Scalability
- Normalize messages store layouts by channel ID.
- Render 10,000+ messages feeds without browser lag.
Accessibility (a11y)
- Accessible keyboard channel swap commands.
- Aria announcements on message arrivals.
Security
- Escape chat inputs preventing XSS injections.
- Secure file downloads links access.
Reliability & Failover
- Store channel histories inside IndexedDB for offline access.
- Show delivery fail options on socket disconnects.
Observability
- Monitor local database read latencies.
- Track WebSocket reconnect delays.
4. Core User Flows
Sending a chat message
- User selects workspace and channel.
- Chat input composer registers keystroke.
- User clicks send; message renders instantly in list (optimistic).
- WebSocket pipes message, receives confirmation, and updates indicator.
5. High-Level Design & Layers
The frontend maintains a normalized client store synced with IndexedDB for offline history, using WebSockets for real-time messages and presence updates.
Frontend Layers
- UI Layer: SidebarWorkspaces, ChatFeed, MessageComposer.
- State Layer: Normalized Redux/Zustand store, local IndexedDB adapter.
- Network Layer: WebSocket connection client.
Major Components
- MessageList: Virtualized scrolling message panel recycling chat rows.
- PresenceManager: Coordinates client presence status updates.
Data Flow Pipelines
- 1. Active channel selection updates state.
- 2. MessageList queries IndexedDB, rendering cached logs.
- 3. API adapter fetches new messages in background.
- 4. Sockets append live arrivals.
6. Component Architecture & State Boundaries
| Component | Responsibility | State Owned | Dependencies |
|---|---|---|---|
| ChatShell | Manages channels lists, message scrolls, and toolbar components. | Active channel ID, messages array | MessageList, MessageComposer |
7. State Management
Local UI State
- composer text values
- Sidebar open toggles
Server Query Cache State
- User profile details
- Workspace configurations
Global/Shared State
- Active channel ID
- Normalized messages map
Real-Time & Sync State
- Real-time messages feeds
- Presence status indicators
8. API Contracts Design
GET/api/v1/channels/:id/messages?limit=50
Get Channel MessagesPurpose: Download channel messages history.
Sample Response:
{
"messages": [
{
"id": "m1",
"text": "Hello",
"user": "u1"
}
]
}9. Caching Strategy
Browser/HTTP Cache
- IndexedDB stores message history logs.
- Local storage caches token details.
Edge CDN Caching
- Edge cache application assets.
Application Cache
- Zustand stores active channel lists.
Invalidation Policies
- Clear channel logs cache on channel deletion.
10. System Strategies Checklist
Performance Strategy & Budgets
- Virtualize message scrolling grids.
- Lazy load sidebar detail channels components.
- Optimistically render message additions.
Inclusive Accessibility Design
- Use keyboard shortcuts to navigate chat lists.
- Add alt text to message attachments.
Security Safeguards & Risks
- Escape HTML markup in message composer blocks.
- Restrict script scopes using CSP headers.
Telemetry & Production Observability
- Monitor channel transition times.
- Log database write failures.
Graceful Failure & Resilience
- Buffer pending messages, retrying on reconnect.
- Show offline warning indicators.
Deployment, Rollout & CDN topologies
- PWA deployment cached using Service Workers.
- BFF layer maps backend data schemas.
11. Architectural Decisions & Tradeoffs
Decision: IndexedDB local-first storage vs direct API queries
Benefit:
Instant channel swaps and offline capabilities.
Drawback:
Requires complex client sync and merge logic.
When To Use: When building high-volume chat platforms.
12. Interview Answer Framework
How to structure your defense of this architecture during a 45-minute technical system design session:
1. Opening Pitch
Explain that chat applications require normalized state architectures. Contrast normal client states with local-first IndexedDB models.
2. Requirement Clarification Queries
- Do we need support for offline messaging?
- Should we support message reactions?
3. Core High-Level Architecture Block
Detail a ChatShell binding workspaces lists, Virtualized MessageList, and WebSocket engines.
4. Strategic Deep Dive Areas
- Explain normalized stores patterns.
- Detail DOM recycling inside chat feeds.
5. Summary & Defensive Tradeoffs
Conclude by highlighting synchronization priorities (messages sequence keys, database write speeds).
13. Common Pitfalls & Extension Questions
Candidate Mistakes to Avoid
- Not virtualizing message scrolls, causing lag after a week of chat history loads.
- Storing messages in a flat unnormalized list, causing full page re-renders on minor reactions edits.
Interviewer Follow-ups / Extensions
- How would you build a client-side full-text search engine over local histories?
- How do you resolve message updates sequence conflicts?