Distributed Systems Interview Questions 2026 — What Senior Engineers Get Asked

At Flipkart's 2024 Big Billion Day, their MySQL clusters handled over 1 million queries per second on write-heavy workloads — not through clever caching tricks, but by migrating 900+ standalone MySQL shards to TiDB's Raft-based consensus layer, dropping P99 write latency to 13ms under that load. Distributed systems interview questions in 2026 aren't asking you to recite the CAP theorem. They're asking whether you can reason at that level.

This is the question that separates candidates at Razorpay, Flipkart, Swiggy, Coupang, Stripe, and Walmart. Not "explain eventual consistency" — that's table stakes. The real question is: "You're building the payment deduction flow. The bank API is flaky. What guarantees do you need, and how do you architect for them?" Everything in this post is aimed at getting you to answer that fluently.

What Senior Interviewers Actually Probe in 2026

The standard distributed systems interview list — CAP theorem, Raft, consistent hashing — isn't wrong. It's incomplete. What interviewers at Razorpay, Flipkart, and Coupang are actually diagnosing:

• Can you connect consistency models to real product decisions, not textbook definitions?
• Do you know where systems fail in production?
• Can you reason through trade-offs on a scenario you haven't memorized?

The 12 Distributed Systems Interview Questions That Actually Get Asked

Ordered by frequency across interviews at Razorpay, Flipkart, Swiggy, Coupang, and Walmart. The first three appear in nearly every senior interview. The last four are Staff+/architect-level.

Consistency Models: The Question Behind the Question

Q: You're designing a like counter on a social feed at 500K writes per second globally. What consistency model do you pick?

The trap: candidates answer "eventual consistency" immediately because they know it scales, and then can't explain the mechanism that makes it correct.

The full answer: G-Counter CRDT with eventual consistency. A G-Counter (grow-only counter) assigns each replica its own counter slot. Each replica increments only its own slot. To read the global count, sum all slots. To merge two replicas, take the element-wise max of each slot. The key property: merging is commutative and idempotent — it doesn't matter which order replicas sync or if a sync message arrives twice. The count is always correct after convergence.

Why not a distributed atomic counter under strong consistency? At 500K writes/sec globally, every increment would require a quorum write — a round trip to at least 2 of 3 data centers. At 100ms inter-region latency, you'd be throughput-limited to ~10 writes/sec. The math doesn't work.

Why not last-write-wins? Because two concurrent increments from different regions would overwrite each other. LWW is for values that replace each other (user profile photo URL). It's wrong for accumulators.

The five consistency models you must be able to rank and apply:

| Model | Guarantee | Used by | When to pick it | |---|---|---|---| | Linearizability | Every op appears instantaneous; reads always see latest write | ZooKeeper, etcd, Google Spanner | Distributed locks, leader election, config management | | Sequential consistency | All ops in some sequential order; each process sees its ops in order | Early Cassandra | Theoretical — rarely built directly | | Causal consistency | Causally related ops seen in same order everywhere | DynamoDB (with vector clocks), CRDTs | Social feeds, collaborative editing, comment threads | | Monotonic read | Never see older value after newer one | Session guarantees on replicas | User-facing reads after own writes | | Eventual consistency | All replicas converge given no new writes | Cassandra, S3, DynamoDB default | Likes, views, shopping carts, DNS TTL |

CAP Theorem — The Real Interview Trap

Q: Apply CAP to choosing between ZooKeeper and Cassandra for distributed rate limiting.

Most candidates define CAP correctly. They fail on the application question.

What CAP actually means: During a partition, choose consistency (refuse to serve rather than return stale data) or availability (keep serving, possibly stale). Partition tolerance isn't optional — partitions happen in every production network.

PACELC matters more than CAP: When there's no partition (99.9% of operating time), there's still a trade-off between latency and consistency. Spanner waits for a global commit — consistency over latency. DynamoDB's eventually consistent reads are ~1ms faster than strongly consistent reads — latency over consistency. Most engineering effort goes into the Else clause, not the Partition clause.

The rate limiter answer: CP (ZooKeeper/etcd): during a partition, users can't make requests — availability drops. Correct only if over-counting is catastrophic (financial quota). AP (Redis): two regions count independently during a partition, you might allow 2× the limit briefly. Acceptable for standard API rate limiting.

For API rate limiting: Redis token bucket per region, accept occasional partition-period over-admission. For fraud prevention: CP, accept the availability hit.

The follow-up: "What if the rate limiter itself goes down?" Fallback policy — fail open (continue serving) or fail closed (reject all). Fail open for non-financial rate limiting; fail closed for fraud. This is independent of the consistency choice.

Raft Consensus — Where It Actually Gets Tested

Q: How does Raft handle leader election, and what's the split-brain problem? How do fencing tokens solve it?

This is where answers diverge sharply at Staff+ level.

Raft basics (you need this cold): Three roles — Leader, Follower, Candidate. Each follower has a randomized election timeout (150–300ms). If a follower doesn't receive a heartbeat from the Leader within that window, it becomes a Candidate, increments its term, votes for itself, sends RequestVote RPCs. First Candidate to get majority votes wins. Normal operation: all writes go through the Leader, which appends to its log, sends AppendEntries to followers, commits once a majority acknowledges.

Why random timeouts? Deterministic timeouts cause synchronized elections — all followers start at once, split the vote, no one wins. Randomness ensures one Candidate starts before others and usually wins before they become Candidates.

The split-brain problem: A partition creates two island groups. If both elect a leader, they accept writes independently — two sources of truth. In a 5-node cluster split 3-and-2: the 3-node island has majority and elects a leader normally. The 2-node island can't reach majority and stops serving writes. Temporary unavailability on the minority side instead of data divergence.

Fencing tokens add a second layer: Even with quorum, a zombie leader (partitioned but not dead) might still try to write to shared storage after a new leader is elected. A fencing token is a monotonically increasing number issued on every leadership change. Every write to shared storage must carry the current token; writes with a lower token are rejected. A zombie leader's writes fail at the storage layer even if it doesn't know it's been replaced.

Elasticsearch before v7 was notorious for split-brain: default minimum_master_nodes=1 allowed a 2-node partition to elect two masters. Fixed in v7 with quorum-based voting.

Partitioning — The Hotspot Question

Q: You're partitioning a 10TB user-activity table by user_id. Your top 0.1% of users generate 40% of writes. How do you handle it?

This appears at every company with user-generated content: Swiggy (order history), Flipkart (product activity), Coupang (purchase logs).

Why consistent hashing isn't enough: 256 virtual nodes distribute keys evenly — but only if keys are uniformly distributed. A hot user generating 40% of writes still maps to one virtual node, one physical shard. Consistent hashing distributes the average; it doesn't fix the extreme.

The four real solutions:

1. Write sharding on hot keys: Append a random suffix to hot user IDs: user_id:0, user_id:1, ... user_id:N. Writes distribute across N shards. Reads require a scatter-gather across all N shards to reconstruct the full history. Correct for write-heavy hot keys where read fan-out is acceptable.

2. Identify hot keys at write time: Maintain a hot-key registry (Redis sorted set by write rate). When a write arrives for a known hot key, route to a pre-sharded key space. Amazon DynamoDB's adaptive capacity uses exactly this — it automatically identifies hot partitions and rebalances.

3. Tiered storage for hot users: Hot users' recent activity goes to an in-memory tier (Redis, ScyllaDB). Historical activity goes to columnar storage (Parquet on S3). ScyllaDB's shard-per-core architecture reduces inter-core contention for hot keys.

4. CQRS + event sourcing: Command side: append-only event log per user. Query side: materialized views built asynchronously. Log append is O(1) regardless of user activity volume. Swiggy's order history is append-only into Kafka; read models are built from it separately.

Distributed Transactions — 2PC vs Saga

Q: What's the difference between two-phase commit and the Saga pattern? When does Saga fail?

2PC: Coordinator sends Prepare to all participants; each locks resources and responds Ready. If all Ready, coordinator sends Commit. Blocking failure: if the coordinator crashes between Prepare and Commit, all participants are locked indefinitely — waiting forever for a Commit or Rollback that may never arrive. Used safely within a single cluster (PostgreSQL 2PC for cross-shard in Citus). Breaks down for long-running transactions across services.

Saga: Break the distributed transaction into local transactions, each publishing an event. If a step fails, trigger compensating transactions. Non-blocking — no global lock.

Where Saga fails (the non-obvious part): Saga trades atomicity for availability. There's no isolation between steps — other transactions see intermediate state. A Flipkart order Saga: (1) reserve inventory → (2) charge payment → (3) notify warehouse. Step 3 fails; compensating transaction refunds step 2. But between steps 2 and 3, another process may have read "payment charged, order confirmed" and acted on it. Isolation violation. This is why Sagas need idempotent compensating transactions and careful duplicate-detection at each step.

Razorpay's pattern: idempotency keys on every mutation, at-least-once delivery via Kafka, Flink exactly-once checkpointing with idempotent sinks using deduplicate keys (tenant:service:entity:window_start). The idempotency key is the primary guard against double-charges from Saga retries.

Replication — Leaderless vs Leader-Based

Q: What are the trade-offs between leader-based and leaderless replication?

Leader-based (MySQL, PostgreSQL, MongoDB, Kafka): All writes go through a single leader; followers replicate asynchronously or synchronously. Breaks down when the leader becomes a write bottleneck or cross-region writes face round-trip latency. Data loss risk under async replication on failover — this is exactly why Flipkart migrated their Altair MySQL system (900+ clusters, async replication) to TiDB's synchronous Raft layer, eliminating in-flight write loss on leader promotion.

Leaderless (Cassandra, DynamoDB, Riak): Writes go to any node; quorum W + R > N guarantees overlap. With N=3, W=2, R=2, at least one node is always in both write and read sets. Breaks down when concurrent writes from different nodes conflict. Last-write-wins with timestamps loses data when NTP-synchronized clocks diverge by even tens of milliseconds — enough to drop a write. Cassandra's fix: application-level timestamps. Better: CRDTs for conflict-heavy workloads.

Read repair (often missed in interviews): When a leaderless read fetches from multiple replicas and finds divergent values, it returns the newest to the client and asynchronously writes it back to the stale replica. The system heals itself on every read. Anti-entropy is the background job that syncs replicas independent of user reads.

Exactly-Once Delivery — The Three Layers

Q: How do you achieve exactly-once semantics in Kafka?

Candidates answer "idempotent producers and consumers." That's necessary but misses the middle layer. Three independent guarantees are required:

1. Idempotent producers (Kafka 0.11+): Producer assigns a sequence number per partition. Broker tracks the highest sequence per producer and deduplicates retried messages. Exactly-once write to the log.

2. Kafka transactions: Atomic write across multiple partitions. beginTransaction() → writes → commitTransaction(). Consumers with isolation.level=read_committed only see committed messages. Exactly-once for Kafka-to-Kafka hops.

3. Idempotent consumer sinks: Even with the above, the consumer's side effect (database write, payment call) can execute before the offset commits, then replay on restart. Your sink must be idempotent. This is the layer most answers miss. Razorpay uses deduplicate keys (tenant:service:entity:window_start) so reprocessed events are dropped at the sink, not double-applied.

In practice: Kafka transactions add ~5ms overhead per commit. Most teams use at-least-once delivery + idempotent consumers (effectively-once) and skip true Kafka transactions unless cross-partition atomicity is required.

MVCC — The Concept Most Candidates Can't Define

Q: How does MVCC work in distributed databases?

This appears at companies running CockroachDB, TiDB, or Spanner, and in ML feature store interviews. Most candidates know the acronym; few can explain the mechanism.

MVCC (Multi-Version Concurrency Control): Instead of locking a row for a write, the database keeps multiple versions simultaneously. A write creates a new version with a newer timestamp. A read uses a snapshot timestamp — it sees the version current at that point, never seeing in-progress writes. Writers don't block readers. Readers don't block writers.

Why it matters for distributed systems: A CockroachDB transaction might read from 5 nodes. MVCC with a consistent snapshot timestamp lets all 5 return their versions as-of the same logical time. Without it, you'd need global read locks that serialize every read — a throughput killer at scale.

The production gotcha: PostgreSQL stores old row versions in the heap itself. If VACUUM falls behind, old versions accumulate and the table bloats. Heavily-written tables need aggressive autovacuum tuning. CockroachDB's GC runs per-range and is decoupled from user operations — cleaner at scale but adds its own GC pressure.

Fault Tolerance — The Circuit Breaker Failure Mode Interviews Miss

Q: Walk me through the circuit breaker pattern. When does it fail to protect you?

Three states: Closed (normal operation), Open (fail fast, return cached/default response), Half-Open (one test call; success → Closed, failure → Open).

The gap: A circuit breaker tripping on error rate (e.g., 50% errors over 10s) won't protect you from a slow downstream service that's returning 200 OK in 8 seconds instead of 100ms. Your thread pool fills with slow-but-successful requests, your p99 spikes, and the circuit stays Closed. Solution: also trigger on latency percentile breach — Resilience4j's slowCallRateThreshold does exactly this. Netflix Hystrix uses the same approach.

Exponential backoff with jitter: Retry wait: 1s, 2s, 4s, 8s — plus ±20% random jitter. Without jitter, all retrying clients hit the recovering service simultaneously (thundering herd), which prevents recovery. Jitter spreads the load and gives the service room to breathe.

Bulkhead pattern: Separate thread pools per downstream dependency. Service A's 10-second calls don't starve Service B's threads. Named after ship compartments — one compartment flooding doesn't sink the ship.

The AI Infrastructure Connection

Q: How do distributed systems concepts apply to ML infrastructure?

This question appears at Flipkart ML, Swiggy Data Science, and Walmart Global Tech AI platform interviews.

Feature store consistency: A feature store has an online store (Redis, fast) and an offline store (BigQuery/S3, high throughput). Training-serving skew happens when the feature used at training time diverges from what's available at serving time. This is a distributed consistency problem, not a pipeline problem. Systems like Feast solve it by writing features to both stores through a single write path, with the offline store as source of truth and the online store as a refresh cache. An etcd coordination layer tracks the current feature version.

Distributed training as consensus: AllReduce in PyTorch DDP is a synchronization barrier — all workers must agree on the gradient before any can take the next step. Ring-AllReduce routes gradients through a ring topology: each node accumulates and passes along, reducing bandwidth from O(N²) for naive all-to-all to O(1) per node.

Model serving across regions: The consistency decision — do all regions serve the same model version simultaneously? CP approach: Raft-coordinated global version bump, all regions switch atomically, lower availability during rollout. AP approach: regions can briefly serve different versions during a rollout. Correct if model versions are backward-compatible.

The Thing Everyone Gets Wrong: Consistency Is a Per-Operation Decision

The most common interview mistake: treating consistency as a system-wide property you choose once at deployment.

Razorpay uses strong consistency for debit operations (linearizable reads from primary, synchronous replication) and eventual consistency for analytics dashboards (any replica, delay acceptable). Same system, different models per operation.

The decision framework:

Is incorrect data worse than unavailability?
  → YES: CP. Refuse to serve rather than return wrong data.
  → NO:  AP. Serve stale data rather than show an error.

Within AP:
  Accumulator (counter, cart) → CRDT (G-Counter, PN-Counter, OR-Set)
  Value (profile photo URL)   → LWW with application-level conflict detection

Within CP:
  Tolerable unavailability window?
  → Seconds: Raft with synchronous replication
  → Milliseconds: not achievable multi-region — accept the physics

Swiggy's order tracker uses this split: driver location updates are eventually consistent (10-second staleness is fine; write throughput matters). Order state machine transitions (PLACED → CONFIRMED → PICKED UP → DELIVERED) are linearizable — a phantom delivery is worse than a brief error. One system, two models, applied per operation.

How to Practice These Until They're Automatic

Reading about distributed systems builds vocabulary. It doesn't build the response speed and trade-off reasoning that interviewers are measuring. The Swiggy SDE-2 interview gives you 45 minutes to design a real-time order tracking system — the consistency model decision happens in the first 5 minutes, and how you frame it determines whether the rest of the session is collaborative or adversarial.

The System Design module on KnowEase covers each concept in this post with structured practice problems — you design a system, make the consistency and partitioning choices, and get AI feedback on whether your reasoning holds. The distributed systems questions here are the foundation; the system design module is where you practice applying them under time pressure.

If you're targeting Flipkart, Razorpay, or Coupang specifically, the product company interview guide breaks down the specific system design formats and what each company weights in their loop.

Quick Reference: The 8 Most Tested Concepts

| Concept | One-line answer | Production example | Where it breaks | |---|---|---|---| | CAP theorem | During partition: pick availability or consistency | Cassandra (AP) vs etcd (CP) | PACELC matters more in normal ops | | Raft consensus | Single leader, majority quorum, append-only log | etcd (Kubernetes), TiDB, CockroachDB | Leader bottleneck; split-brain without fencing | | Consistent hashing | Map keys to virtual ring; move O(1/N) keys on change | Redis Cluster, Cassandra | Hot keys still hot; vnodes help but don't cure | | CRDT | Merge without coordination; commutative + idempotent | Like counters, shopping carts, collaborative editing | Complex semantics; not all operations are CRDT-expressible | | Saga pattern | Local transactions + compensating transactions | Flipkart order creation, Razorpay payout | No isolation; intermediate states visible | | MVCC | Keep multiple row versions; readers don't block writers | PostgreSQL, CockroachDB, TiDB | Vacuum bloat (Postgres); GC pressure in distributed variants | | Circuit breaker | Fail fast; protect thread pool from slow dependencies | Netflix Resilience4j, Envoy proxy | Slow calls (not errors) don't trip it without explicit latency thresholds | | Fencing tokens | Monotonic write token; stale leaders rejected at storage | etcd leases, ZooKeeper epoch numbers | Requires storage layer cooperation; can't fence if storage doesn't check |

The question that actually predicts distributed systems mastery isn't "what is linearizability?" — it's "your order service just double-charged 200 users during a Kafka consumer restart. Walk me through why it happened and how you'd prevent it." If you can answer that fluently — naming the missing idempotency key, the at-least-once delivery semantic, the non-idempotent payment sink — you've understood distributed systems at the level that gets you hired at the companies on this list. Everything else is preparation.