A payment service publishes 'PaymentCaptured' events to a Kafka topic with 12 partitions, keyed by customer_id. A downstream ledger consumer must apply debits and credits per account in the exact order they occurred. During a rebalance, the team notices some accounts briefly process events out of order. What is the MOST likely root cause?
- A. Kafka does not guarantee ordering, so per-account ordering is impossible without an external sequencer
- B. The producer uses acks=1 instead of acks=all, corrupting offsets
- C. A consumer committed offsets before fully processing in-flight records, so after rebalance another consumer reprocessed and interleaved them ✓
- D. The 12 partitions exceed the consumer count, forcing round-robin delivery that ignores keys
Correct answer: C. Kafka preserves order within a partition, so out-of-order symptoms during rebalance almost always stem from committing offsets before processing completes, causing reprocessing/interleaving.
You run PostgreSQL with one primary and two asynchronous read replicas. A user updates their profile (write to primary), is redirected, and the next read hits a replica showing stale data. You must guarantee that a user always reads their own writes without forcing all reads to the primary. Which approach BEST achieves read-your-writes here?
- A. Switch replication to synchronous for both replicas so all reads are current
- B. Track the primary's LSN at write time and route that user's subsequent reads to a replica only once its replay LSN has caught up, else the primary ✓
- C. Add a Redis cache in front of the replicas with a 5-second TTL
- D. Enable REPEATABLE READ isolation on the replica connections
Correct answer: B. Capturing the write's LSN and gating replica reads until the replica has replayed past it gives per-session read-your-writes without making every read hit the primary.
A Saga orchestrator coordinates: ReserveInventory, ChargeCard, then CreateShipment. ChargeCard succeeds but CreateShipment fails permanently. The compensating action for ChargeCard is RefundCard, which itself times out and is retried. To keep the system correct under these retries, RefundCard MUST be:
- A. Idempotent and keyed by the saga/transaction id so repeated invocations refund at most once ✓
- B. Executed inside a distributed 2PC transaction with ChargeCard
- C. Fire-and-forget, since eventual consistency tolerates duplicate refunds
- D. Ordered strictly after all other compensations complete
Correct answer: A. Compensating actions run under at-least-once retry semantics, so they must be idempotent (keyed by transaction id) to avoid double refunds.
An event-sourced 'Account' aggregate rebuilds state by replaying all events on every command, and hot accounts now have 400k+ events, making command latency unacceptable. Which technique directly addresses this WITHOUT abandoning event sourcing?
- A. Delete old events older than 90 days to shrink the stream
- B. Snapshot aggregate state periodically and replay only events after the latest snapshot ✓
- C. Move the write model to a relational table and drop the event log
- D. Increase the aggregate's in-memory cache TTL
Correct answer: B. Snapshotting stores a materialized state at a version so replay only processes events after the snapshot, cutting rebuild cost while preserving the full event log.
A REST endpoint POST /transfers is called by clients that retry on network timeouts. Occasionally a timeout occurs after the server committed the transfer but before the response reached the client, so the retry creates a duplicate transfer. The cleanest server-side fix is:
- A. Return 200 instead of 201 so clients stop retrying
- B. Make clients wait 30s before any retry to avoid races
- C. Require an Idempotency-Key header; persist the key with the result and return the stored result on any replay ✓
- D. Switch the endpoint from POST to PUT so it becomes naturally idempotent
Correct answer: C. An idempotency key persisted with the operation's result lets the server detect replays and return the original outcome instead of re-executing, which PUT alone does not solve for create-with-side-effects.
You need zero data loss (RPO=0) for a write-heavy OLTP system even if an entire AWS region fails. Which topology genuinely meets RPO=0, and what is its unavoidable cost?
- A. Asynchronous cross-region replication; cost is higher storage only
- B. Synchronous cross-region replication of every commit; cost is added write latency bounded by inter-region round-trip time ✓
- C. Periodic cross-region snapshots every 60 seconds; cost is a 60s data window
- D. Single-region Multi-AZ with synchronous replicas; cost is compute overhead
Correct answer: B. RPO=0 across regions requires the commit to be durable in the remote region before acknowledging, which forces synchronous replication and pays the inter-region latency on every write; async and snapshots both allow data loss, and Multi-AZ does not survive a region loss.
A CQRS system writes orders to the command store and asynchronously projects them into a read model. A user places an order and is immediately shown an order list that omits it, generating support tickets. Without making the projection synchronous, the correct mitigation is:
- A. Add a database trigger that copies writes into the read model inside the same transaction
- B. Have the client optimistically render the just-submitted order from the command response until the projection catches up ✓
- C. Poll the read model every 100ms server-side and block the response until the order appears
- D. Switch the read model to strong consistency by reading from the command store for all queries
Correct answer: B. CQRS read models are eventually consistent by design; surfacing the write's own result optimistically on the client bridges the projection lag without collapsing the read/write separation.
gRPC service A calls service B with a 200ms deadline. B calls C, but B forwards a fresh 200ms deadline to C instead of propagating the remaining budget. Under load, what pathological behavior emerges?
- A. C rejects all calls because deadlines cannot be forwarded in gRPC
- B. B keeps waiting on C after A has already timed out and abandoned the request, wasting resources on doomed work ✓
- C. A's deadline silently extends to 400ms due to additive propagation
- D. C processes requests twice because deadlines trigger retries
Correct answer: B. Deadlines must propagate as the remaining budget; resetting to a full 200ms lets C keep working after A has given up, causing wasted work and cascading overload (work amplification).
You are strangling a monolith. A new 'Pricing' microservice must read customer data that still lives in the monolith's schema, whose column names and enums are messy legacy artifacts. To prevent the legacy model from leaking into the new service, you should:
- A. Have Pricing query the monolith's tables directly using the legacy column names for speed
- B. Introduce an anti-corruption layer that translates the legacy model into Pricing's clean domain model at the boundary ✓
- C. Copy the monolith schema verbatim into the Pricing database to avoid translation
- D. Expose the monolith tables via a shared ORM used by both services
Correct answer: B. An anti-corruption layer translates between the legacy and new domain models at the boundary, preventing legacy concepts from corrupting the new bounded context.
A globally distributed key-value store is configured for a quorum with N=3 replicas. To guarantee that reads always see the latest acknowledged write, which R/W setting satisfies the quorum overlap condition W + R > N with the LOWEST read latency?
- A. W=1, R=3
- B. W=2, R=2
- C. W=3, R=1 ✓
- D. W=1, R=1
Correct answer: C. W+R>N requires overlap; W=3,R=1 satisfies 4>3 and makes reads touch only one replica (lowest read latency) at the cost of slower writes.
In an eventually consistent system, which technique helps resolve conflicting concurrent writes?
- A. Vector clocks or CRDTs ✓
- B. A single global lock
- C. Increasing the cache TTL
- D. Rounding timestamps to seconds
Correct answer: A. Vector clocks and CRDTs capture causality so concurrent updates can be detected and merged deterministically.
Which shard key choice best avoids hotspots?
- A. The record creation timestamp
- B. A boolean status flag
- C. A high-cardinality, evenly distributed key ✓
- D. The customer's country
Correct answer: C. A high-cardinality, uniformly distributed key spreads writes evenly and prevents hot shards.
What is the Saga pattern primarily used for?
- A. Compressing images at the edge
- B. Managing distributed transactions across services ✓
- C. Load balancing across regions
- D. Encrypting inter-service traffic
Correct answer: B. A Saga coordinates a distributed transaction as a sequence of local steps with compensating actions.
What is a key drawback of two-phase commit (2PC)?
- A. It cannot guarantee atomicity across nodes
- B. It cannot abort a transaction once the prepare phase has begun
- C. It silently loses committed data if a participant node restarts
- D. It blocks resources and the coordinator is a single point of failure ✓
Correct answer: D. 2PC holds locks while waiting and stalls if the coordinator fails, hurting availability and throughput.
In a Dynamo-style quorum with N replicas, which condition guarantees a read sees the latest write?
- A. R + W > N ✓
- B. R + W < N
- C. R = W = 1
- D. R + W = N
Correct answer: A. When read and write quorums overlap (R + W > N), every read intersects the most recent write set.
When a circuit breaker is in the OPEN state, what does it do?
- A. Retries the dependency on every request
- B. Fails fast without calling the failing dependency ✓
- C. Caches the last successful response forever
- D. Routes traffic to a read replica
Correct answer: B. In the open state the breaker short-circuits calls immediately to give the failing dependency time to recover.
What is a key disadvantage of heavy synchronous inter-service calls?
- A. Failures can cascade and services become tightly coupled ✓
- B. They cannot transmit JSON payloads
- C. They always violate the CAP theorem
- D. They require a message broker to function
Correct answer: A. Synchronous chains propagate latency and failures downstream, coupling service availability together.
What does the Bulkhead pattern isolate?
- A. Database rows during a transaction
- B. API keys per client tenant
- C. Logs by severity level
- D. Resources so one failure doesn't sink the whole system ✓
Correct answer: D. The bulkhead partitions resources (e.g., thread pools) so a failure in one area cannot exhaust the rest.
How is exactly-once processing typically approximated in a distributed queue?
- A. Disabling all retries on the broker
- B. Idempotent consumers with message deduplication ✓
- C. Setting the visibility timeout to zero
- D. Using a single consumer thread only
Correct answer: B. Since brokers deliver at-least-once, idempotent consumers plus dedup keys yield effectively-once results.
What is the Strangler Fig pattern used for?
- A. Incrementally replacing a legacy system piece by piece ✓
- B. Throttling abusive API clients
- C. Compressing responses to save bandwidth
- D. Balancing load across availability zones
Correct answer: A. The Strangler Fig routes functionality to new services gradually until the legacy system can be retired.
During a network partition, how does a CP (consistency-partition) system behave?
- A. It sacrifices availability to preserve consistency ✓
- B. It sacrifices consistency to preserve availability
- C. It guarantees both consistency and availability
- D. It shuts down all nodes entirely
Correct answer: A. A CP system rejects or blocks requests during a partition rather than return inconsistent data.
Which technique best mitigates the 'thundering herd' problem when a hot cache key expires?
- A. Request coalescing with a lock so only one request refills the cache ✓
- B. Removing TTLs entirely from all keys
- C. Increasing the number of clients
- D. Switching every write to write-back
Correct answer: A. Coalescing/locking ensures one request repopulates the cache while others wait, avoiding a stampede on the origin.
What is the main drawback of the two-phase commit (2PC) protocol?
- A. It blocks if the coordinator fails, reducing availability ✓
- B. It requires every participant to run the same database vendor
- C. It cannot guarantee atomicity
- D. It commits each participant independently with no prepare phase
Correct answer: A. 2PC is a blocking protocol; participants can be stuck holding locks if the coordinator crashes mid-commit.
How does the Saga pattern maintain consistency across microservices?
- A. A sequence of local transactions with compensating actions on failure ✓
- B. A single global distributed lock across all services
- C. A shared monolithic database for all services
- D. Synchronous two-phase commit across services
Correct answer: A. Sagas use a chain of local transactions and issue compensating transactions to undo work if a step fails.
When is a wide-column store like Cassandra preferred over a traditional RDBMS?
- A. High write throughput with known query patterns and horizontal scale ✓
- B. Complex ad-hoc joins across many tables
- C. Strong multi-row ACID transactions
- D. Small datasets on a single node
Correct answer: A. Cassandra excels at high write throughput and linear horizontal scaling when queries are designed up front.
What does the 'sidecar' pattern in a service mesh enable?
- A. Offloading cross-cutting concerns like mTLS and retries into a co-located proxy ✓
- B. Storing the service's primary database
- C. Compiling the microservice at runtime
- D. Fully replacing the external load balancer
Correct answer: A. A sidecar proxy handles networking concerns (mTLS, retries, telemetry) outside the application code.
To approximate exactly-once processing in a distributed event pipeline, you typically combine:
- A. Idempotent consumers with message deduplication via IDs or offsets ✓
- B. At-most-once delivery with no tracking
- C. Fire-and-forget messaging
- D. Synchronous blocking calls only
Correct answer: A. Idempotent consumers plus dedup tracking make at-least-once delivery behave effectively exactly-once.
In an active-active multi-region deployment, what is the hardest problem to solve?
- A. Conflict resolution for concurrent writes across regions ✓
- B. Serving static assets from edge caches
- C. Provisioning compute in each region
- D. Configuring DNS routing
Correct answer: A. Concurrent writes in multiple regions can conflict, requiring conflict-resolution strategies like CRDTs or last-writer-wins.
What does a DynamoDB strongly consistent read guarantee?
- A. The read reflects all writes that succeeded before the read began ✓
- B. The read is always eventually consistent
- C. The read uses serializable snapshot isolation
- D. The read never returns the latest value
Correct answer: A. A strongly consistent read returns the most up-to-date data reflecting all prior successful writes.
What is the principal trade-off introduced by database sharding?
- A. Cross-shard queries and transactions become complex ✓
- B. Total storage capacity decreases
- C. Single-shard reads become slower
- D. The system loses the ability to scale horizontally
Correct answer: A. Sharding scales writes and storage but makes queries or transactions spanning multiple shards significantly harder.