Bird
Raised Fist0

Back-of-the-Envelope Estimation with Real Numbers - Servers, Storage, Bandwidth

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/7
API Gateway

Receives client estimation request

Validates and parses request, prepares event for Kafka

Protocol:HTTP REST
BeforeClient request not yet received by system
AfterRequest parsed and ready to be published to Kafka
Kafka Cluster

Publishes estimation request event

Stores event durably for downstream consumers

Protocol:Kafka Publish
BeforeEvent not yet persisted in Kafka
AfterEvent durably stored in Kafka topic partition
Cache Layer (Redis Cluster)

Checks cache for existing estimation result

If cache miss, waits for Cassandra query result

Protocol:Redis GET
BeforeNo cached estimation result for request key
AfterCache miss triggers Cassandra DB query
Cassandra DB

Queries estimation data for request

Returns stored estimation numbers to cache layer

Protocol:CQL Query
BeforeCache miss requires DB lookup
AfterEstimation data retrieved from Cassandra
Cache Layer (Redis Cluster)

Stores fresh estimation data in cache

Sets TTL for cache entry to optimize future requests

Protocol:Redis SET
BeforeCache missing estimation data
AfterCache populated with fresh estimation data
API Gateway

Returns estimation result to client

Sends cached or fresh data as HTTP response

Protocol:HTTP REST Response
BeforeEstimation data available in cache
AfterClient receives estimation result
Monitoring & Alerting

Records request latency and success metrics

Triggers alert if latency exceeds threshold

Protocol:Metrics Collection
BeforeNo metrics recorded for this request
AfterMetrics updated; alerts triggered if needed
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────┐
│    API Gateway    │
│  (REST + WebSocket)│
└─────────┬─────────┘
          │ HTTP Request
          ▼
┌───────────────────┐
│  Kafka Cluster    │
│ (Event Streaming) │
└─────────┬─────────┘
          │ Kafka Publish
          ▼
┌───────────────────────────┐
│ Cache Layer (Redis Cluster)│
│    (Fast Key-Value Store) │
└─────────┬─────────────────┘
          │ Redis GET/SET
          ▼
┌───────────────┐
│ Cassandra DB  │
│ (Wide-Column  │
│   Storage)    │
└───────┬───────┘
        │ CQL Query
        ▼
┌───────────────────────┐
│ Monitoring & Alerting  │
│  (Metrics + Alerts)    │
└───────────────────────┘
Design Rationale

This architecture handles estimation requests by first receiving them at the API Gateway, which validates and forwards events to the Kafka Cluster for durable streaming. The Cache Layer (Redis) attempts to serve requests quickly by checking for cached results. On cache misses, Cassandra DB is queried for persistent storage of estimation data. Fresh data is then cached for future requests. Monitoring & Alerting continuously tracks system health and request latency, enabling proactive issue detection. This design balances low latency via caching with durability and scalability through Kafka and Cassandra, ensuring efficient and reliable estimation data delivery.

Primary Focus

✓

Practice

(1/5)
1. A real-time location tracking system must efficiently query nearby devices within a geographic radius with low latency. Which component is best suited to handle these geo-spatial queries?
easy
A. A relational database with spatial extensions (e.g., PostGIS) for all queries
B. A geo-indexing service like a geospatially-enabled NoSQL store (e.g., Redis GEO or Elasticsearch)
C. A message queue to buffer location updates before querying
D. A CDN to cache location data for faster access

Solution

  1. Step 1: Identify geo-indexing role

    Relational DBs with spatial extensions provide accuracy but have higher latency and poor horizontal scaling for frequent geo queries.

  2. Step 2: Evaluate alternatives

    Message queues buffer data but do not support geo queries. CDNs cache static content, not dynamic geo data.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Geo-indexing NoSQL stores optimize radius queries with low latency [check]
Hint: Geo-indexing NoSQL stores excel at fast radius queries [check]
Common Mistakes:
2. If the authentication service in a client-server system becomes unavailable, what is the exact failure mode experienced by clients attempting to log in?
medium
A. Clients receive a generic server error but can retry immediately without data loss
B. Clients are authenticated locally by the server, so login proceeds without interruption
C. Clients' login requests hang until timeout, then receive authentication failure with no retry
D. Clients are redirected to a backup authentication service automatically

Solution

  1. Step 1: Understand authentication dependency

    The server relies on the authentication service for validating credentials; if unavailable, requests cannot be processed.

  2. Step 2: Trace failure impact

    Without authentication service, login requests hang waiting for response until timeout, then fail with no automatic retry or fallback.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Unavailable auth service causes login hang then failure [check]
Hint: No auth service -> login hangs then fails, no fallback [check]
Common Mistakes:
3. At 10x scale, which component in the food delivery system is most likely to fail first and why?
hard
A. The restaurant discovery cache, because memory limits prevent caching all restaurants in all regions
B. The relational database storing orders, because write throughput exceeds disk I/O capacity
C. The driver assignment service, because maintaining stateful WebSocket connections for all drivers prevents horizontal scaling
D. The notification service, because push notification providers throttle requests at high volume

Solution

  1. Step 1: Identify stateful components at scale

    Driver assignment maintains WebSocket connections, which are stateful and tied to server memory.

  2. Step 2: Analyze scaling bottlenecks

    WebSocket connections cannot be easily sharded or moved; adding servers doesn't migrate existing connections, causing resource exhaustion.

  3. Step 3: Compare other components

    Databases (A) can be sharded; caches (C) can evict; notification services (D) can batch or retry.

  4. Final Answer:

    Option C -> Option C

  5. Quick Check:

    Stateful WebSocket connections -> driver assignment service bottleneck [check]
Hint: Stateful WebSocket connections block driver service scaling [check]
Common Mistakes:
4. At 10x scale, which component in the RTMP to HLS pipeline is most likely to fail first due to stateful connection limits, and why?
hard
A. The CDN edge nodes, because cache invalidation overhead grows exponentially
B. The transcoder cluster, because CPU-intensive video encoding can't be parallelized further
C. The Kafka cluster, because partition count cannot increase beyond a fixed limit
D. The RTMP ingest servers, because each maintains a stateful TCP connection per broadcaster limiting horizontal scaling

Solution

  1. Step 1: Identify stateful bottlenecks

    RTMP ingest servers maintain stateful TCP connections per broadcaster, limiting how many connections each server can handle.

  2. Step 2: Compare scaling constraints

    Transcoders (A) can be scaled horizontally with more instances. Kafka (C) can add partitions but has practical limits. CDN edges (D) scale well with caching. RTMP ingest (B) hits connection limits first due to TCP statefulness.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Stateful TCP connections on RTMP ingest servers limit horizontal scaling [check]
Hint: Stateful TCP connections limit RTMP ingest server scaling first [check]
Common Mistakes:
5. At 10x scale, which component in the URL Shortener system is most likely to become the first bottleneck, and why?
hard
A. The Redirect Service, because it maintains stateful HTTP connections that cannot be easily sharded
B. The Analytics pipeline, because batch processing delays increase with volume
C. The Cache layer, because it runs on a single node and cannot scale horizontally
D. The Database, because it cannot handle the increased number of writes for new short codes

Solution

  1. Step 1: Identify stateful components

    Redirect Service holds stateful HTTP connections (e.g., WebSocket or session affinity), limiting horizontal scaling.

  2. Step 2: Compare scaling challenges

    Database and Cache can be sharded or scaled horizontally; Analytics pipeline can be scaled with more workers; Redirect Service's stateful connections cause scaling bottleneck first.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful Redirect Service limits horizontal scaling, causing first bottleneck [check]
Hint: Stateful services limit scaling before DB or cache do [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard