Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

The data model splits across three storage systems, each chosen for the access pattern it serves. The interesting decision is not the schema itself but why a single database cannot serve all three workloads efficiently.

PostgreSQL: Core Entities

users
user_id UUID Primary Key
email VARCHAR Unique, indexed
name VARCHAR
password_hash VARCHAR
created_at TIMESTAMP

activities
activity_id UUID Primary Key
user_id UUID Foreign Key -> users
type VARCHAR (running, cycling, weightlifting)
start_time TIMESTAMP Indexed (user_id, start_time DESC)
duration_sec INTEGER
distance_m INTEGER
calories INTEGER
hr_avg SMALLINT
hr_max SMALLINT
gps_storage_key VARCHAR (S3 key for GPS track)
source VARCHAR (manual, phone_gps, apple_watch)
idempotency_key UUID Unique, indexed
created_at TIMESTAMP

goals
goal_id UUID Primary Key
user_id UUID Foreign Key -> users
goal_type VARCHAR (weekly_distance, weekly_frequency)
target_value INTEGER
start_date DATE
end_date DATE (nullable for recurring)
created_at TIMESTAMP

The composite index on (user_id, start_time DESC) enables the most common query: "show me my recent activities" without a full table scan. The idempotency_key column with a unique constraint prevents duplicate uploads at the database level, a second layer of defense after the Redis check.

Why PostgreSQL for this layer? Activity summaries involve relational queries: joining activities with goals to compute progress, filtering by date ranges, aggregating distance by week. These are SQL's strengths. The data volume (90 GB/year for summaries) is well within PostgreSQL's comfort zone.

S3: GPS Track Storage

Bucket: fitness-gps-tracks
Key pattern: {user_id}/{activity_id}.gpx.gz

GPS tracks are stored as compressed GPX files in S3. Each track is write-once (uploaded after workout completion) and read-rarely (only when a user views the route map). S3 provides effectively unlimited storage at a fraction of PostgreSQL's per-GB cost.

The key includes user_id as a prefix for two reasons: S3 distributes objects across partitions based on key prefix, and grouping by user enables efficient bulk exports ("download all my data").

Redis: Cache and Ephemeral State

Key: dashboard:{user_id}
Value: { weekly_distance, weekly_activities, goal_progress, streak }
TTL: 300 seconds

Key: idempotency:{key}
Value: { activity_id, status }
TTL: 86400 seconds (24 hours)

Key: active_stream:{activity_id}
Value: sorted set of GPS points (score = timestamp)
TTL: 14400 seconds (4 hours, max workout duration)

Redis serves three roles: caching dashboard data to avoid repeated PostgreSQL aggregations, storing idempotency keys for upload deduplication, and buffering live GPS stream data before it is flushed to permanent storage.

A single PostgreSQL instance could technically store everything: summaries, GPS tracks as BYTEA columns, and cache data in materialized views. The problem emerges at scale. GPS blobs in PostgreSQL inflate table size, slow VACUUM operations, and compete for shared buffer cache with the high-frequency summary queries. Separating hot relational data from cold binary blobs lets each storage layer operate in its sweet spot.

The core engineering challenge (the GATE of this problem) is building a reliable offline-to-online sync pipeline that handles intermittent connectivity, duplicate uploads, and concurrent multi-device edits without losing or corrupting workout data. Every component in this section exists to solve some aspect of that challenge.

Key Insight

The GATE insight: the fundamental difficulty is that the client, not the server, is the source of truth during a workout. The phone records data for an hour with no server contact, then must sync reliably when connectivity returns. This offline-first inversion drives the idempotency design, conflict resolution, and the entire sync protocol.

Offline Sync Engine

Offline sync: the mobile app records workouts locally in SQLite, queues them for upload when connectivity returns, and uses idempotency keys to prevent duplicates.

The mobile app maintains a local SQLite database that mirrors the server's activity schema. During a workout, all data is written to SQLite first, regardless of network availability. When the workout ends, the app adds the activity to an upload queue. A background sync worker processes this queue whenever the network is available.

Queue processing: The sync worker reads the oldest unsynced activity from SQLite, sends it to the API with the idempotency key (generated when the workout started), and marks it as synced only after receiving a 201 response. If the request fails (timeout, 5xx error), the worker retries with exponential backoff. If the server returns 409 Conflict (idempotency key already exists), the worker marks the activity as synced without creating a duplicate.

Multi-device conflict resolution: A user edits an activity title on their phone while their watch simultaneously uploads a heart rate correction. The server uses last-write-wins with per-field granularity: the phone's title change and the watch's heart rate update are independent fields, so both are applied. For conflicting edits to the same field (both devices change the title), the server accepts the write with the later client-side timestamp. The activity row includes a version number that increments on every update, enabling optimistic concurrency control.

Real-Time GPS Ingestion

GPS ingestion: mobile app streams points via WebSocket to the Ingestion Service, which buffers in Redis and flushes to S3 in batches.

The GPS Ingestion Service manages WebSocket connections for live workout tracking. Each active workout maintains a Redis sorted set where incoming GPS points are stored with their timestamp as the score.

Buffer and flush cycle: Every 30 seconds, a background job reads the sorted set for each active workout, serializes the points into a compressed GPX segment, appends it to the workout's S3 object, and trims the sorted set. This batching reduces S3 writes from 3,600 per hour (one per second) to 120 per hour (one per 30 seconds).

Connection recovery: When a WebSocket connection drops (common on mobile), the client buffers GPS points locally. Upon reconnection, it sends all buffered points in a single batch. The Redis sorted set handles out-of-order arrival naturally: points are ordered by timestamp score regardless of when they arrive.

Scaling: Each Ingestion Service instance handles roughly 10,000 concurrent WebSocket connections. At 50,000 peak concurrent workouts, 5 instances are needed. Auto-scaling monitors active connection count and launches new instances when utilization exceeds 70%.

Goal Evaluation Pipeline

Goal evaluation: Kafka delivers activity events to the Goal Service, which computes progress, updates the database, and triggers notifications for achieved goals.

The Goal Service consumes activity_created events from Kafka and evaluates each against the user's active goals. The evaluation process queries PostgreSQL for the user's goals and current-period activity totals, computes whether any goal was advanced or completed, and updates the goal progress record.

Batched evaluation: When a user logs multiple activities in quick succession (such as during a bulk import), the Goal Service deduplicates evaluations: if multiple events for the same user arrive within a 5-second window, they are processed as a single batch, querying the database once instead of N times.

Notification trigger: When a goal is achieved, the Goal Service publishes a goal_achieved event to Kafka. The Notification Service consumes this event and sends a push notification to the user's devices. The decoupling ensures that goal evaluation and notification delivery are independent: a slow notification provider does not delay goal processing.

Tradeoffs

Every architectural decision involves a trade-off. Understanding these trade-offs, and being able to articulate them in an interview, demonstrates deliberate design thinking.

SQL vs. NoSQL for Activity Storage

PostgreSQL (our choice) provides ACID transactions, rich query capabilities (joins for goal evaluation, aggregations for dashboards), and strong consistency for activity records. The trade-off: vertical scaling limits throughput to roughly 10K writes/sec on a single primary. At 500K activities/day (6/sec average, 100/sec peak), PostgreSQL handles this comfortably.

Cassandra or DynamoDB would offer unlimited horizontal write scaling. But activity queries require joins (activities with goals), range aggregations (sum distance this week), and transactional consistency (idempotent uploads). NoSQL databases make all of these harder. The data volume (90 GB/year) does not justify the operational complexity of a distributed NoSQL cluster.

Our reasoning: use SQL until you outgrow it. At 10x the current scale (10M DAU, 5M activities/day), you would shard PostgreSQL by user_id or migrate hot paths to DynamoDB. Premature NoSQL adoption is a common interview mistake.

Common Pitfall

A common interview pitfall is choosing Cassandra or DynamoDB 'for scale' when the data volume is under 100 GB/year. Interviewers want to see you justify the complexity. At 90 GB/year, PostgreSQL with proper indexing handles the workload. Save NoSQL for when you have concrete evidence that SQL is the bottleneck.

Offline-First vs. Server-First Architecture

Offline-first (our choice) means the client stores all data locally and syncs to the server asynchronously. This maximizes reliability during workouts but introduces complexity: sync queues, idempotency, conflict resolution, and storage management on the client.

Server-first means the client sends data to the server in real-time and relies on the server as the source of truth. Simpler to implement, but any connectivity loss during a workout results in data loss.

Our reasoning: for a fitness app, data loss during a workout is unacceptable. Users cannot re-run their morning 10K. The complexity of offline-first is justified by the domain requirement.

WebSocket vs. HTTP Polling for Live GPS

WebSocket (our choice) maintains a persistent connection for streaming GPS points every second. Efficient for high-frequency data, but requires connection state management on the server and complicates load balancing (sticky sessions or connection-aware routing).

HTTP polling would have the client POST GPS points every N seconds. Simpler server architecture (stateless), but at 1-second intervals the TCP handshake overhead wastes 10-20% of each interval on mobile networks.

Our reasoning: the 1-second GPS sampling rate makes WebSocket the clear winner. If we relaxed to 30-second intervals (like some hiking apps), HTTP polling would be viable and simpler.

Failure scenarios

The system's reliability depends on graceful degradation: each component can fail independently without losing user workout data. Every failure scenario maps to a specific architectural decision.

S3 Unavailability During Activity Upload

Scenario: S3 returns errors during a burst of activity uploads after a popular evening workout window.

What happens: The Activity Service cannot upload GPS tracks. Rather than failing the entire upload, the service writes the activity summary to PostgreSQL with gps_storage_key set to "pending." The GPS track is queued in a retry buffer (either in-memory with disk overflow or in Kafka). A background job retries S3 uploads with exponential backoff. When S3 recovers, pending tracks are uploaded and the activity record is updated.

Why this works: The user sees their workout summary immediately. The GPS route map shows "processing" briefly. No data is lost because the client retains the GPS track until the server confirms receipt.

Redis Failure

Scenario: The Redis cluster loses a node, reducing cache capacity by one-third.

What happens: Cache hit rate drops from 95% to roughly 65%. Dashboard reads that would hit Redis now fall through to PostgreSQL. PostgreSQL read replicas absorb the additional load, increasing dashboard latency from 5ms (cached) to 30ms (database). The idempotency check falls back to the PostgreSQL unique constraint, adding 10ms to upload latency.

Why this works: Redis is a performance optimization, not a correctness requirement. The system functions correctly (just slower) without it. When Redis recovers, the cache repopulates organically through cache-aside on reads.

Interview Tip

A strong interview answer categorizes each component's failure mode: Redis failure degrades performance, Kafka failure delays downstream processing, S3 failure delays GPS availability. Only PostgreSQL failure would actually block activity uploads. This hierarchy of failure impacts shows you understand which components are on the critical path.

Kafka Unavailability

Scenario: Kafka becomes unreachable, preventing the Activity Service from publishing events.

What happens: Activity uploads still succeed (PostgreSQL write is the critical path). The Activity Service writes undelivered events to the PostgreSQL outbox table. Goal evaluations and analytics updates are delayed until Kafka recovers and the outbox is drained. Users see their new activities but goal progress may lag briefly.

Why this works: The outbox pattern decouples the critical path (activity storage) from the event distribution path. Kafka unavailability degrades timeliness, not correctness.

WebSocket Connection Storm

Scenario: A major running event causes 100,000 simultaneous WebSocket connections, 2x the normal peak.

What happens: Auto-scaling detects the connection count spike and launches additional Ingestion Service instances. During the scale-up window (1-2 minutes), some new connections are rejected with a 503 status. The mobile app falls back to local buffering and retries the WebSocket connection with exponential backoff. GPS data is never lost because the client always records locally first.

Why this works: The offline-first design means server-side capacity constraints never cause data loss. Users recording their marathon are unaffected; the WebSocket stream is an optimization for live tracking display, not a requirement for data capture.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10