Bird
Raised Fist0

Graph Databases - When Relationships Are the Primary Data

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Client API Server

Receives graph query from client

Client sends a relationship-centric graph query over WebSocket

Protocol:WebSocket
BeforeClient has composed graph query but not sent
AfterQuery received by Client API Server, ready for routing
Query Router

Publishes query event to Kafka

Query Router serializes and sends query event to Kafka topic

Protocol:Kafka
BeforeQuery Router has query in memory, not yet published
AfterQuery event durably stored in Kafka for processing
Kafka Event Streaming

Queues query event for downstream consumers

Kafka holds query event, ensuring ordered delivery to consumers

Protocol:Kafka
BeforeKafka topic empty or with prior events
AfterQuery event appended to Kafka topic partition
Graph Storage Cluster (Apache Cassandra)

Reads graph data for query

Cassandra executes CQL queries to fetch relationship data

Protocol:Cassandra CQL
BeforeCassandra stores graph data, no query in progress
AfterRelevant graph data retrieved and ready for compute
Graph Compute Cluster (Apache Spark GraphX)

Processes graph computation

Spark GraphX performs relationship analytics on retrieved data

Protocol:Spark RPC
BeforeGraph data loaded, computation not started
AfterComputation results generated for analytics
Analytics Database (Apache Druid)

Ingests computation results

Druid ingests aggregated graph analytics for fast querying

Protocol:Druid ingestion API
BeforeDruid holds prior analytics data, no new ingestion
AfterNew analytics data available for dashboard queries
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   Client API Server    │
└────────────┬──────────┘
             │ WebSocket
             ▼
┌───────────────────────┐
│     Query Router      │
└────────────┬──────────┘
             │ Kafka
             ▼
┌───────────────────────────────┐
│   Kafka Event Streaming        │
└────────────┬──────────────────┘
             │ Cassandra CQL
             ▼
┌─────────────────────────────────────────┐
│ Graph Storage Cluster (Apache Cassandra)│
└────────────┬────────────────────────────┘
             │ Spark RPC
             ▼
┌──────────────────────────────────────────┐
│ Graph Compute Cluster (Spark GraphX)     │
└────────────┬─────────────────────────────┘
             │ Druid ingestion API
             ▼
┌───────────────────────────────┐
│   Analytics Database (Druid)  │
└───────────────────────────────┘
Design Rationale

This architecture emphasizes relationship-centric graph data processing. The Client API Server receives queries over WebSocket and forwards them to the Query Router. The Query Router publishes query events to Kafka, ensuring durability and ordered processing. Kafka acts as a buffer and event queue, decoupling ingestion from processing. The Graph Storage Cluster, implemented with Apache Cassandra, stores graph data optimized for relationships and serves queries via CQL. The Graph Compute Cluster uses Apache Spark GraphX to perform complex graph computations on retrieved data. Finally, aggregated results are ingested into Apache Druid, an analytics database optimized for fast querying of time-series and aggregated data. This design separates storage, compute, and analytics, enabling scalable, fault-tolerant graph processing focused on relationships.

Primary Focus

✓

Practice

(1/5)
1. A distributed key-value store must evenly distribute keys across nodes and handle node failures without massive data reshuffling. Which component primarily enables this?
easy
A. Gossip protocol to propagate membership and failure information
B. Vector clocks to resolve conflicting versions of data
C. Consistent hashing to assign keys to nodes with minimal remapping
D. Quorum-based replication to ensure data durability

Solution

  1. Step 1: Identify the role of consistent hashing

    Consistent hashing distributes keys to nodes such that when nodes join or leave, only a small subset of keys need reassignment, minimizing reshuffling.

  2. Step 2: Eliminate other components

    Vector clocks handle version conflicts but do not distribute keys. Gossip protocol manages cluster membership but not key distribution. Quorum replication ensures durability but does not affect key assignment.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Consistent hashing minimizes key remapping on node changes [check]
Hint: Consistent hashing minimizes key remapping on node changes [OK]
Common Mistakes:
2. A real-time ML inference system must serve predictions with minimal latency while allowing safe model updates without downtime. Which component best enables seamless model rollout with instant rollback capability?
easy
A. Shadow mode deployment that runs new models in parallel without affecting live traffic
B. A/B testing framework that splits traffic evenly between models
C. Batch inference pipeline that processes data offline and updates predictions periodically
D. Feature store that caches input features for faster model access

Solution

  1. Step 1: Identify deployment strategies for safe model updates

    Batch inference (C) is offline and adds latency, so it doesn't support real-time rollout. Feature store (D) optimizes input features but doesn't handle rollout or rollback. A/B testing (A) splits live traffic, risking user experience if the new model is faulty.

  2. Step 2: Understand shadow mode benefits

    Shadow mode (B) runs new models in parallel on live data without affecting production responses, enabling validation and instant rollback if issues arise.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Shadow mode runs new models safely alongside production [check]
Hint: Shadow mode isolates new models without impacting live traffic [OK]
Common Mistakes:
3. In a message delivery system, at step 4 the Delivery Worker checks the recipient's presence cache TTL. What happens if the TTL has expired?
easy
A. The Delivery Worker immediately marks the message as delivered without sending
B. The Delivery Worker queues the message for offline delivery and does not mark it delivered
C. The Delivery Worker retries sending the message indefinitely until TTL refreshes
D. The Delivery Worker deletes the message assuming recipient is unreachable

Solution

  1. Step 1: Understand Delivery Worker behavior on expired presence TTL

    If TTL expired, recipient is considered offline; message must be queued for later delivery, not marked delivered (A and D are incorrect). Retrying indefinitely (C) wastes resources.

  2. Step 2: Confirm queuing for offline delivery

    Delivery Worker queues message for offline delivery and waits for recipient presence refresh.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Expired TTL -> queue message, no delivery mark [check]
Hint: Expired presence TTL means offline; queue message, don't mark delivered [check]
Common Mistakes:
4. For a system launching with unpredictable hot keys, which cache warming strategy balances freshness and resource usage best?
medium
A. Use a hybrid approach combining historical access logs with real-time monitoring to selectively warm keys
B. Preload all possible keys regardless of traffic patterns to ensure zero misses
C. Only warm keys that were hot in the previous launch period, ignoring recent changes
D. Rely solely on lazy loading to avoid unnecessary warming overhead

Solution

  1. Step 1: Analyze warming strategies for unpredictable hot keys

    Hybrid approach uses historical and real-time data to adaptively warm relevant keys.

  2. Step 2: Eliminate extremes

    Preloading all keys wastes resources; ignoring recent changes misses new hot keys; lazy loading causes latency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Hybrid warming adapts to traffic changes balancing freshness and cost [check]
Hint: Hybrid warming adapts to traffic changes balancing freshness and cost [check]
Common Mistakes:
5. If the Market Data Feed component crashes and stops publishing updates, what is the exact failure observed by external clients subscribing to real-time stock prices?
medium
A. Clients receive stale prices indefinitely with no indication of failure
B. Clients receive partial updates but with delayed timestamps causing confusion
C. Clients receive an error message and automatic reconnection attempts begin
D. Clients continue receiving cached data from the Matching Engine without updates

Solution

  1. Step 1: Understand Market Data Feed failure impact

    When Market Data Feed crashes, it stops pushing updates; clients detect connection loss and receive error events triggering reconnection.

  2. Step 2: Eliminate other options

    Clients receive stale prices indefinitely with no indication of failure is wrong because clients detect connection loss; Clients receive partial updates but with delayed timestamps causing confusion is wrong because partial updates don't occur without feed; Clients continue receiving cached data from the Matching Engine without updates is wrong because Matching Engine doesn't serve cached market data.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Feed crash -> clients get error + reconnect attempts [check]
Hint: Feed crash triggers client error and reconnect [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