Bird
Raised Fist0

Time-Series Databases - Metrics, Events, and IoT Patterns

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

Receives new metric event

HTTP POST with JSON payload from IoT sensor

Protocol:HTTP POST
BeforeMetric event exists only on IoT device
AfterMetric event accepted and published to Kafka
Kafka Cluster

Stores metric event

Appends event to partition keyed by metric_id

Protocol:Kafka Publish
BeforeEvent published by Ingestion API but not durably stored
AfterEvent durably stored in Kafka partition log
Write Workers

Consume event from Kafka and write to Cassandra

Parse event and insert time-series data points

Protocol:Kafka Consume + CQL Insert
BeforeEvent present in Kafka but not in Cassandra
AfterEvent data persisted in Cassandra DB
Query Service

Receives query for recent metrics

Executes CQL queries to Cassandra for raw or downsampled data

Protocol:CQL Query
BeforeData stored in Cassandra but not yet queried
AfterQuery results returned to client
Retention & Downsampling Worker

Periodically reads old data and writes downsampled data

Compacts old raw data into summarized form in Cassandra

Protocol:CQL Read/Write
BeforeOld raw data stored in Cassandra
AfterDownsampled data stored; raw data may be expired
Cassandra DB

Stores and serves time-series data

Persists raw and downsampled metrics, supports queries

Protocol:CQL Insert/Query
BeforeData in transit or being processed by workers
AfterData durably stored and available for queries
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────┐
│   Ingestion API   │
└─────────┬─────────┘
          │ HTTP POST (JSON metrics/events)
          ▼
┌───────────────────┐
│  Kafka Cluster    │
│  (Partitioned by  │
│   metric_id)      │
└─────────┬─────────┘
          │ Kafka Publish
          ▼
┌───────────────────┐
│   Write Workers   │
│ (Consume from     │
│  Kafka, write to  │
│  Cassandra DB)    │
└─────────┬─────────┘
          │ CQL Insert
          ▼
┌───────────────────┐
│   Cassandra DB    │
│ (Time-series data │
│  storage)         │
└─────────┬─────────┘
          │ Query Request (CQL)
          ▼
┌───────────────────┐
│   Query Service   │
│ (Reads raw or     │
│  downsampled data)│
└─────────┬─────────┘
          │ Scheduled Trigger
          ▼
┌───────────────────────────────┐
│ Retention & Downsampling Worker│
│ (Reads old data, writes down-  │
│  sampled data back to Cassandra│
└───────────────────────────────┘
Design Rationale

This architecture handles high-volume time-series data ingestion and querying. The Ingestion API accepts metric events via HTTP and publishes them to a Kafka cluster partitioned by metric_id to maintain ordering. Write Workers consume from Kafka and persist data into Cassandra, a scalable time-series database optimized for writes and queries. The Query Service reads raw or downsampled data from Cassandra to serve client queries efficiently. Meanwhile, the Retention & Downsampling Worker runs periodically to compact old data, reducing storage costs and improving query performance by storing summarized metrics. This design balances durability, scalability, and query efficiency for metrics, events, and IoT data.

Primary Focus

✓

Practice

(1/5)
1. A search ranking system must store and serve feature vectors for millions of users with low latency. Which component is best suited to provide fast, consistent feature retrieval at scale?
easy
A. A relational database with complex joins to compute features on demand
B. A distributed in-memory feature store with precomputed feature vectors
C. A batch processing system that recomputes features daily and stores them in object storage
D. A key-value store without versioning or consistency guarantees

Solution

  1. Step 1: Identify feature retrieval requirements

    Low latency and consistency for millions of users require fast, precomputed feature access.

  2. Step 2: Evaluate component suitability

    A relational DB with joins (A) is too slow for real-time; batch recomputation (C) is stale; key-value store without consistency (D) risks stale or inconsistent features. Distributed in-memory feature store (B) provides fast, consistent retrieval.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    In-memory feature store -> low latency, consistent features [check]
Hint: Precompute features in-memory for fast, consistent retrieval [check]
Common Mistakes:
2. In the failover incident trace, at Step 4 the Database Proxy receives a client query after the primary node crashed. What state does the proxy enter before forwarding the query?
easy
A. Marks the primary as unavailable and routes query to the new leader after election
B. Returns an error to the client without retrying
C. Queues the query indefinitely until the old primary recovers
D. Immediately forwards query to the old primary node, causing timeout

Solution

  1. Step 1: Trace Database Proxy behavior at Step 4

    Upon detecting primary failure, the proxy marks it unavailable and waits for leader election to complete before routing queries to the new leader.

  2. Step 2: Eliminate other options

    Forwarding immediately to old primary (A) causes timeouts; queuing indefinitely (C) stalls clients; returning errors without retry (B) reduces availability.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Proxy reroutes queries only after leader election [check]
Hint: Proxy reroutes only after leader election completes
Common Mistakes:
3. For a high-traffic public API requiring both strong security and minimal latency, which TLS configuration trade-off is most appropriate?
medium
A. Use TLS 1.3 with ephemeral key exchange to enable forward secrecy and reduce handshake latency
B. Use self-signed certificates to avoid certificate chain overhead
C. Disable certificate validation to speed up connections
D. Use TLS 1.0 with RSA key exchange for compatibility

Solution

  1. Step 1: Evaluate TLS versions and key exchange

    TLS 1.3 supports ephemeral key exchange (ECDHE) which provides forward secrecy and reduces handshake round trips, lowering latency.

  2. Step 2: Eliminate other options

    Use TLS 1.0 with RSA key exchange for compatibility uses outdated TLS 1.0 and RSA key exchange lacking forward secrecy and higher latency. Disable certificate validation to speed up connections compromises security by disabling validation. Use self-signed certificates to avoid certificate chain overhead risks trust issues and is unsuitable for public APIs.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    TLS 1.3 ephemeral keys -> forward secrecy + lower latency [check]
Hint: TLS 1.3 ephemeral keys = forward secrecy + low latency [check]
Common Mistakes:
4. If the health check component is removed from a load balancer using Least Connections, what failure occurs?
medium
A. The load balancer continues to distribute requests evenly, but some servers may be down causing request failures
B. The load balancer switches to Round Robin automatically, losing connection count accuracy
C. The load balancer caches server states incorrectly, causing stale routing decisions
D. The load balancer sends requests to unhealthy servers, causing increased latency and failed connections without fallback

Solution

  1. Step 1: Role of health checks in Least Connections

    Health checks detect server availability; without them, the balancer cannot exclude unhealthy servers.

  2. Step 2: Behavior without health checks

    Least Connections relies on accurate connection counts and server health; without health checks, it cannot trust connection data and typically falls back to Round Robin.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Without health checks, Least Connections falls back to Round Robin losing load awareness [check]
Hint: No health checks -> Least Connections falls back to Round Robin [check]
Common Mistakes:
5. You must design a REST API for a resource that supports partial updates. Which approach best balances client flexibility and server complexity?
medium
A. Use HTTP PUT with the full resource representation for every update
B. Use HTTP PATCH with JSON Patch format for partial updates
C. Use HTTP POST to a custom /update endpoint with partial data
D. Use HTTP PUT with query parameters specifying fields to update

Solution

  1. Step 1: Compare HTTP methods for partial updates

    PUT requires full resource; PATCH supports partial updates natively.

  2. Step 2: Evaluate JSON Patch benefits

    JSON Patch is a standardized format allowing precise partial modifications, reducing payload size and server logic.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    PATCH with JSON Patch enables flexible partial updates [check]
Hint: PATCH + JSON Patch = flexible partial updates [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