Bird
Raised Fist0

PACELC Theorem - Beyond CAP for Systems That Must Choose Under Latency

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
API Gateway (Envoy)

Receives client update request

Validates and forwards request to Consistency Coordinator

Protocol:HTTP/REST
BeforeClient request is pending at API Gateway
AfterRequest forwarded to Consistency Coordinator Service
Consistency Coordinator Service

Decides consistency vs latency trade-off

Produces event to Kafka with chosen consistency level

Protocol:Kafka Produce
BeforeRequest received, consistency not yet decided
AfterEvent durably stored in Kafka with metadata
Kafka Cluster

Stores event and makes it available for consumers

Partitions event by key to preserve ordering

Protocol:Kafka Consume
BeforeEvent just produced, not yet consumed
AfterEvent ready for Delivery Workers consumption
Delivery Workers

Consumes event, writes update to Cassandra

Executes CQL write with configured consistency level

Protocol:CQL Write
BeforeEvent pending consumption by Delivery Workers
AfterData updated in Cassandra with consistency guarantees
Delivery Workers

Sends metrics about processing latency and success

Calls Metrics & Logging API to record operation

Protocol:Metrics API
BeforeUpdate completed in Cassandra
AfterMetrics recorded for monitoring and alerting
Cassandra Cluster

Stores updated data

Persists data with chosen consistency level for availability and latency

Protocol:CQL Write
BeforeWrite request received from Delivery Workers
AfterData persisted and available for queries
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│    API Gateway (Envoy)        │
└───────────────┬───────────────┘
                │ HTTP/REST
                ▼
┌───────────────────────────────┐
│Consistency Coordinator Service │
└───────────────┬───────────────┘
                │ Kafka Produce
                ▼
┌───────────────────────────────┐
│        Kafka Cluster           │
└───────────────┬───────────────┘
                │ Kafka Consume
                ▼
┌───────────────────────────────┐
│      Delivery Workers          │
└───────┬─────────────┬─────────┘
        │ CQL Write   │ Metrics API
        ▼            ▼
┌───────────────┐  ┌──────────────────┐
│Cassandra Cluster│  │ Metrics & Logging│
└────────────────┘  └──────────────────┘
Design Rationale

This architecture implements the PACELC theorem by balancing consistency and latency trade-offs. The API Gateway receives client requests and forwards them to the Consistency Coordinator Service, which decides the appropriate consistency level before producing events to Kafka. Kafka acts as a durable, ordered event log, enabling asynchronous processing by Delivery Workers. These workers write updates to Cassandra, a highly available NoSQL database optimized for low latency, respecting the chosen consistency. Finally, Delivery Workers emit metrics to the Metrics & Logging service for observability. This design separates consistency decisions from data storage and leverages Kafka for decoupling, enabling flexible trade-offs between latency and consistency as required.

Primary Focus

✓

Practice

(1/5)
1. If the event ingestion pipeline fails to persist incoming metric data, what is the exact failure observed in the alerting system?
medium
A. Threshold and anomaly detectors receive incomplete data, causing missed or false alerts
B. Alerts are generated with delayed timestamps but eventually delivered
C. Composite alerts continue to function normally using cached inputs
D. The system switches to a backup data source automatically without alert impact

Solution

  1. Step 1: Role of event ingestion pipeline

    This pipeline persists raw metric data for downstream alerting components.

  2. Step 2: Consequence of pipeline failure

    Without persistence, threshold and anomaly detectors get incomplete or missing data, leading to missed alerts or false positives.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Missing data -> detectors miss or misfire alerts [check]
Hint: No data persistence -> detectors get incomplete data, miss alerts [check]
Common Mistakes:
2. If the Write-Behind cache component crashes before flushing buffered writes to the database, what is the exact failure observed?
medium
A. The cache automatically retries writes on restart, ensuring no data loss
B. Writes buffered in cache are lost, causing data loss and inconsistency between cache and database
C. The cache returns stale data, but the database remains consistent with all writes
D. The database blocks writes until the cache recovers, causing system-wide latency spikes

Solution

  1. Step 1: Understand Write-Behind failure impact

    Buffered writes are not yet persisted; if cache crashes, writes are lost.

  2. Step 2: Analyze system behavior

    Database does not block writes; writes are lost, causing inconsistency. Automatic retries require explicit mechanisms.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Write-Behind crash causes lost buffered writes, no DB blocking [check]
Hint: Write-Behind crash loses buffered writes, no DB blocking [check]
Common Mistakes:
3. If the purge API service in a CDN is down, what exactly breaks in the cache invalidation process?
medium
A. Cached content never expires and clients always get stale data
B. Surrogate key invalidations queue up but are not applied, causing delayed invalidation
C. TTL-based expirations continue but manual purge requests fail, so immediate invalidation is lost
D. Client-side cache control headers override server cache, causing inconsistent cache states

Solution

  1. Step 1: Identify purge API role

    Purge API triggers immediate invalidation; TTL expirations are independent and continue.

  2. Step 2: Analyze failure impact

    Without purge API, manual or programmatic immediate invalidations fail; TTL still expires cache eventually; surrogate key invalidations may be separate.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    TTL expirations unaffected; purge requests fail causing delayed invalidation [check]
Hint: Purge API down blocks immediate invalidation, TTL still expires [check]
Common Mistakes:
4. For a high-traffic API with strict memory limits and tolerance for bursty traffic, which rate limiting approach is best and why?
medium
A. Leaky bucket, because it enforces a steady output rate regardless of bursts
B. Sliding window counter, because it tracks exact request times for precise limits
C. Token bucket, because it smooths bursts and uses fixed memory for tokens
D. Fixed window counter, because it uses constant memory and handles bursts at window edges

Solution

  1. Step 1: Analyze memory constraints and burst tolerance

    Sliding window counters require storing timestamps, which grows with request volume, unsuitable for strict memory limits.

  2. Step 2: Fixed window counters use constant memory by counting requests per fixed interval, allowing bursts at window edges but fitting memory constraints

    Token and leaky buckets smooth bursts but require token state management and may not tolerate bursts as well.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Fixed window uses constant memory, tolerates bursts, fits strict memory limits [check]
Hint: Fixed window uses constant memory, sliding window stores timestamps [check]
Common Mistakes:
5. For internal service communication requiring bidirectional streaming with mobile clients that have intermittent connectivity, which approach is best?
medium
A. Use gRPC bidirectional streaming directly for real-time updates
B. Use gRPC unary calls with client-side polling and exponential backoff
C. Use WebSockets with JSON payloads for flexible streaming
D. Use REST long polling to simulate streaming behavior

Solution

  1. Step 1: Analyze client connectivity constraints

    Mobile clients often have intermittent connectivity and poor support for HTTP/2 streaming.

  2. Step 2: Evaluate streaming options

    Direct gRPC streaming (A) is unreliable on mobile. WebSockets (C) add complexity and JSON is less efficient. REST long polling (D) is less efficient and higher latency. Unary calls with polling and backoff (B) handle intermittent connectivity gracefully.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Mobile intermittent -> unary calls + polling with backoff [check]
Hint: Mobile clients -> unary calls + polling, not streaming [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