System Design Interview Communication

📖 Concept

System design communication is as important as the design itself. At senior level, Google expects you to drive the conversation, make trade-officials explicit, and demonstrate architectural thinking.

System Design Interview Framework (45 minutes):

0-5 min:   Requirements gathering & scope definition
5-10 min:  High-level architecture (draw the boxes)
10-30 min: Deep dive into key components
30-40 min: Discuss trade-offs, scalability, failure modes
40-45 min: Wrap up, answer follow-ups

Requirements gathering template:

Functional: What does the system do? (list features, prioritize)
Non-functional: Scale (users, QPS), latency, availability, consistency
Constraints: Offline support? Real-time? Platform (mobile-only, cross-platform)?
Scope: What's in scope for this interview? (always clarify)

Android-specific system design topics:

Design a news feed (Instagram/Twitter)
Design a messaging app (WhatsApp)
Design a ride-sharing app (Uber)
Design offline-first notes app (Google Keep)
Design a photo gallery with sync (Google Photos)
Design a location-tracking app (Google Maps routing)
Design an e-commerce checkout flow

Communication tips:

Start with the user-facing flow, then go deeper
Draw diagrams (even in text — boxes and arrows)
State constraints explicitly before designing
Discuss at least 2 approaches and explain your choice
Proactively address: failure modes, scaling bottlenecks, security

💻 Code Example

codeTap to expand ⛶

1// System Design: Offline-first Notes App (Google Keep style)
2// This is a template for how to structure your answer
3
4/*
5REQUIREMENTS:
6━━━━━━━━━━━━
7Functional:
8  - Create, edit, delete notes (text + checklist)
9  - Sync across devices
10  - Work fully offline
11  - Real-time collaboration (stretch)
12Non-functional:
13  - <100ms local operations
14  - Sync within 5 seconds when online
15  - Eventual consistency ok
16  - Support 10M+ notes per user (over time)
17
18HIGH-LEVEL ARCHITECTURE:
19━━━━━━━━━━━━━━━━━━━━━━━
20┌─────────────────────────────────────┐
21│  Compose UI                        │
22│  ├── NoteListScreen                │
23│  └── NoteEditorScreen              │
24│         ↕                          │
25│  ViewModel (StateFlow)             │
26│         ↕                          │
27│  Repository (source of truth)      │
28│     ↕              ↕               │
29│  Room DB        SyncEngine         │
30│  (local)       ↕         ↕         │
31│           WorkManager   WebSocket  │
32│               ↕              ↕     │
33│           REST API      Real-time  │
34│               ↕              ↕     │
35│           ──── Backend ────        │
36└─────────────────────────────────────┘
37
38KEY DESIGN DECISIONS:
39━━━━━━━━━━━━━━━━━━━━
401. Room as source of truth
41   - All reads from Room (instant, offline-capable)
42   - Writes go to Room first, then sync to server
43   
442. Delta sync with change tracking
45   - Each note has: localVersion, serverVersion, syncState
46   - Pending changes queued in separate table
47   - WorkManager processes queue when online
48
493. Conflict resolution: Field-level merge
50   - Track which fields changed (title, content, color)
51   - If different fields → auto-merge
52   - If same field → LWW with server timestamp
53   
544. Real-time updates: WebSocket when foregrounded
55   - FCM fires WorkManager sync when backgrounded
56   - WebSocket provides instant updates in active session
57
58TRADE-OFFS DISCUSSED:
59━━━━━━━━━━━━━━━━━━━━
60- Full sync vs Delta sync → Delta (bandwidth, battery)
61- LWW vs CRDT → LWW (simpler, acceptable for notes)
62- WebSocket vs SSE → WebSocket (bidirectional for real-time edit)
63- Single DB vs DB-per-note → Single DB (simpler queries, pagination)
64*/

🏋️ Practice Exercise

Practice these system designs (45 min each, timer on):

Design the Android architecture for Instagram's feed + stories
Design a ride-sharing app's driver-rider matching UI
Design Google Photos' gallery with cloud sync and sharing
Design a payment checkout flow with state recovery
Design an offline-first task management app (Todoist/Asana)

For each, document:

Requirements (functional + non-functional)
High-level architecture diagram
Data model (Room entities)
Key API contracts
Sync strategy
Error handling strategy
Trade-offs discussed

⚠️ Common Mistakes

Diving into implementation details before establishing requirements and high-level architecture
Not discussing trade-offs — Google wants to see your decision-making process, not just the answer
Designing only the happy path — always discuss failure modes, edge cases, and degraded states
Ignoring mobile-specific concerns — battery, offline, network transitions, process death
Not drawing diagrams — visual communication is essential, even in text-based interviews

💼 Interview Questions

🎤 Mock Interview

Mock interview is powered by AI for System Design Interview Communication. Login to unlock this feature.

Was this topic helpful?

← PreviousGoogleyness & Leadership Signals Next →Month 1: Foundations (Days 1-30)