Bird
Raised Fist0

Yelp / Proximity Service - Geohash, Quadtree, Nearby Search

HLDhardInterview freq: medium
Choose your preparation mode4 modes available
▶
Request Trace
Step 1/6
Client Apps

Send proximity search request

User requests nearby restaurants with location and radius

Protocol:HTTPS Request (REST)
BeforeUser has location and search radius input ready
AfterRequest sent over HTTPS to API Gateway
API Gateway

Receive and forward request

API Gateway authenticates and forwards request to GeoIndexer Service

Protocol:Internal RPC
BeforeRequest received from Client Apps
AfterRequest forwarded to GeoIndexer Service
GeoIndexer Service

Encode location and query Elasticsearch

GeoIndexer encodes location using Geohash and Quadtree, queries Elasticsearch for matches

Protocol:Elasticsearch Query (REST)
BeforeRequest received with raw location data
AfterNearby locations retrieved from Elasticsearch
GeoIndexer Service

Produce location update event

GeoIndexer produces Kafka event for new or updated location indexing

Protocol:Kafka Produce
BeforeNearby search results retrieved
AfterLocation update event enqueued in Kafka
Kafka

Store and forward event

Kafka stores location update event for consumption by Elasticsearch indexer

Protocol:Kafka Internal
BeforeEvent produced by GeoIndexer Service
AfterEvent durably stored and ready for consumption
Elasticsearch Cluster

Consume event and update index

Elasticsearch consumes Kafka event and updates geo-index with new location data

Protocol:Kafka Consume
BeforeKafka event available for consumption
AfterGeo-index updated with latest location info
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  Client Apps  │
└───────┬───────┘
        │ HTTPS Request (REST)
        ▼
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ Internal RPC
        ▼
┌───────────────────────┐
│  GeoIndexer Service   │
│  (Geohash + Quadtree) │
└───────┬───────────────┘
        │ Kafka Produce
        ▼
┌────────┐
│ Kafka  │
└────┬───┘
     │ Kafka Consume
     ▼
┌───────────────────────┐
│ Elasticsearch Cluster │
│ (Stores geo-indexes)  │
└───────────────────────┘

This architecture supports efficient proximity search by combining Geohash and Quadtree spatial indexing. Client Apps send location-based queries to the API Gateway, which routes them to the GeoIndexer Service. This service encodes locations into spatial indexes and queries Elasticsearch for nearby results. Location updates are asynchronously propagated via Kafka to Elasticsearch, ensuring durable and scalable indexing. The vertical flow emphasizes separation of concerns: API Gateway handles client communication, GeoIndexer manages spatial logic, Kafka provides reliable event streaming, and Elasticsearch offers fast geo-queries. This design balances real-time query responsiveness with eventual consistency for location updates.

Primary Focus

✓

Practice

(1/5)
1. In a Count-Min Sketch system, at step 3 the Update Worker hashes an incoming event key with the second hash function. What happens to the corresponding counter in the sketch at this step?
easy
A. The counter is reset to zero before incrementing
B. The counter at the hashed index is incremented by one
C. The counter is decremented to avoid overcounting
D. The counter is replaced with the maximum of current and new value

Solution

  1. Step 1: Understand Update Worker hashing

    Each hash function maps the event key to an index in the sketch array.
  2. Step 2: Increment counter at hashed index

    The Count-Min Sketch increments the counter at that index to record the event occurrence.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Update increments counters at hash indices to track frequencies [check]
Hint: Update increments counters at hash indices, never resets or decrements [check]
Common Mistakes:
2. A web API needs to enforce a rate limit of 100 requests per minute per user, allowing bursts but avoiding sudden resets at minute boundaries. Which rate limiting approach best fits this requirement?
easy
A. Fixed window counter, resetting counts exactly every minute
B. Sliding window counter, tracking requests over the last 60 seconds continuously
C. Token bucket with fixed refill intervals every minute
D. Leaky bucket with fixed drain rate per minute

Solution

  1. Step 1: Identify burst tolerance and smooth rate enforcement

    Fixed window counters reset abruptly at minute boundaries, causing spikes. Token and leaky buckets enforce steady rates but may not track exact recent usage.
  2. Step 2: Sliding window counters track requests continuously over the last 60 seconds, allowing bursts without sudden resets

    Sliding window counters provide smoother rate limiting by considering recent activity, avoiding boundary effects.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Sliding window smooths rate limits over time, avoiding fixed window spikes [check]
Hint: Sliding window smooths counts over time, fixed resets abruptly [check]
Common Mistakes:
3. A large-scale key-value store needs to quickly filter out non-existent keys before querying a slow backend database. Which component best handles this filtering to reduce backend load?
easy
A. Use a Bloom filter to probabilistically test key existence before backend query
B. Use a relational database index to speed up key lookups
C. Use a distributed cache like Redis to store all keys for exact lookup
D. Use a consistent hashing ring to route keys to backend shards

Solution

  1. Step 1: Identify the filtering requirement

    The system needs a fast, memory-efficient way to filter out keys that definitely do not exist before hitting the slow backend.
  2. Step 2: Evaluate component suitability

    Redis cache storing all keys (A) is expensive and not scalable for huge key sets. Relational DB indexes (C) still require backend queries. Consistent hashing (D) routes keys but does not filter non-existent keys. Bloom filters (B) provide fast probabilistic membership tests with low memory.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Bloom filters reduce backend queries by filtering non-existent keys [check]
Hint: Bloom filters quickly say no before expensive lookups [check]
Common Mistakes:
4. For a large-scale code repository system supporting millions of users, which branching strategy best balances performance and user flexibility?
medium
A. Use a centralized locking mechanism to serialize all branch creation and merges
B. Use lightweight branch pointers referencing immutable commits with eventual consistency
C. Use full branch copies stored separately for each user to avoid conflicts
D. Use synchronous replication of branch metadata across all servers before allowing merges

Solution

  1. Step 1: Analyze branching strategies for scale

    Lightweight branch pointers referencing immutable commits allow fast branch creation and merges without locking, supporting high concurrency.
  2. Step 2: Evaluate other options

    Centralized locking serializes operations, hurting performance; full branch copies waste storage and complicate merges; synchronous replication adds latency and reduces availability.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Immutable commits + lightweight pointers -> scalable branching [check]
Hint: Immutable commits enable lightweight, scalable branches [check]
Common Mistakes:
5. If the client fails to validate the server's certificate chain during the TLS handshake, what is the most likely failure observed in the connection?
medium
A. The client proceeds with encrypted communication but logs a warning
B. The client aborts the handshake and the connection is terminated without data exchange
C. The server retries sending the certificate chain automatically
D. The client falls back to unencrypted HTTP automatically

Solution

  1. Step 1: Understand client certificate validation failure

    If the client detects an invalid certificate chain, it aborts the handshake and terminates the connection to prevent insecure communication.
  2. Step 2: Analyze options

    The client proceeds with encrypted communication but logs a warning is incorrect because clients do not proceed with encryption if validation fails. The server retries sending the certificate chain automatically is incorrect; servers do not retry sending certificates automatically. The client falls back to unencrypted HTTP automatically is incorrect because clients do not downgrade to HTTP automatically.
  3. Final Answer:

    Option C -> Option C
  4. Quick Check:

    Client aborts handshake on certificate validation failure [check]
Hint: Certificate validation failure -> handshake abort, no fallback [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