Question 1

Explain the CAP Theorem and PACELC Theorem with real-world database examples.

Accepted Answer

The **CAP Theorem** states that a distributed system can only provide at most 2 out of 3 guarantees during a network partition:
- **CP (Consistency + Partition Tolerance)**: Rejects writes/reads if data sync cannot be guaranteed across nodes (e.g. HBase, MongoDB with strict write concerns).
- **AP (Availability + Partition Tolerance)**: Returns stale data rather than erroring (e.g. Cassandra, DynamoDB).

### PACELC Theorem:
Extends CAP:
- **If Partition (P)**: Choose between Availability (A) or Consistency (C);
- **Else (E)**: Choose between Latency (L) or Consistency (C).
Example: DynamoDB defaults to PA/EL (prioritizes availability during partitions, low latency normally).

Key Takeaway: System design requires balancing consistency against availability and network latency depending on business SLAs.

Question 2

What is Vertical Scaling (Scale Up) vs Horizontal Scaling (Scale Out)?

Accepted Answer

Evaluating server scaling paradigms:

1. **Vertical Scaling (Scale Up)**: Adding more CPU, RAM, or SSD storage to a single server instance.
   - *Pros*: Zero architectural changes; simple single-server setup.
   - *Cons*: Hard hardware limit, single point of failure (SPOF), exponential cost growth.
2. **Horizontal Scaling (Scale Out)**: Adding more server instances to a pool behind a Load Balancer.
   - *Pros*: Infinite scaling potential, fault tolerance, cost-effective commodity hardware.
   - *Requirements*: Requires **stateless application services** and centralized session storage (Redis).

Key Takeaway: Design systems to scale horizontally using stateless server pools behind load balancers.

Question 3

How do Load Balancers distribute traffic (Round Robin, Least Connections, IP Hash)?

Accepted Answer

A **Load Balancer** acts as a reverse proxy traffic cop, routing incoming client requests across a pool of backend servers:

### Load Balancing Algorithms:
- **Round Robin**: Routes requests sequentially across the server pool ($S_1 \rightarrow S_2 \rightarrow S_3 \rightarrow S_1$).
- **Least Connections**: Directs new traffic to the server with the fewest active connection sockets (ideal for long-lived HTTP/WebSocket sessions).
- **Weighted Round Robin**: Assigns higher traffic ratios to more powerful server instances.
- **IP Hash**: Hashes the client IP address to route the user to the same server consistently (Sticky Sessions).

Key Takeaway: Use Layer 7 Load Balancers with Least Connections or Weighted Round Robin to distribute traffic evenly across server pools.

Question 4

What is a Content Delivery Network (CDN) and how does Edge Caching reduce latency?

Accepted Answer

A **Content Delivery Network (CDN)** is a geographically distributed network of **Point of Presence (PoP)** edge servers that cache static assets (images, JS, CSS, video chunks) close to end users:

### Benefits & Mechanics:
1. **Latency Reduction**: Serves assets from an edge node located 10ms away instead of fetching from an origin server 200ms away.
2. **Origin Offloading**: Reduces bandwidth and CPU load on origin web servers by up to 90%.
3. **DDoS Protection**: Absorbs volumetric Layer 3/4 network attacks at the edge.

Key Takeaway: Deploy CDNs to cache static media and API responses at edge PoPs globally, reducing user latency and shielding origin servers.

Question 5

What are Caching Strategies (Cache-Aside, Read-Through, Write-Through, Write-Back)?

Accepted Answer

Selecting appropriate caching patterns balances read latency, write performance, and data consistency:

- **Cache-Aside (Lazy Loading)**: Application queries Cache. If Cache Miss $\rightarrow$ Reads Database $\rightarrow$ Writes to Cache $\rightarrow$ Returns. Highly resilient.
- **Read-Through**: Application reads exclusively from Cache. The cache transparently fetches missing keys from DB.
- **Write-Through**: Application writes to Cache; Cache synchronously writes to DB before returning success.
- **Write-Back (Write-Behind)**: Application writes to Cache; Cache asynchronously queues DB writes in the background (Fastest writes, risk of data loss on cache crash).

Key Takeaway: Use Cache-Aside for read-heavy workloads, Write-Through for strict data consistency, and Write-Back for high write throughput.

Question 6

What are Database Read Replicas and Data Sharding?

Accepted Answer

Differentiating database scaling techniques:

- **Database Read Replicas**: Replicates data asynchronously from a single Primary (Write) database to multiple secondary Read Replicas. Scales READ throughput ($O(N)$ replicas). Writes still bottleneck on the Primary master!
- **Data Sharding**: Partitions large database tables horizontally across **multiple independent primary database servers** using a Shard Key (e.g. 'user_id % 4'). Scales WRITE throughput and storage capacity horizontally.

Key Takeaway: Deploy Read Replicas to scale read-heavy workloads, and Database Sharding when write volume or dataset size exceeds a single server.

Question 7

What is Stateless vs Stateful Service Architecture?

Accepted Answer

Designing scalable web application tiers:

- **Stateless Architecture**: Application servers store zero client session state in local memory. Any request can be processed by any server instance. Session state is offloaded to a shared distributed cache (Redis) or JWTs. Enables instant **auto-scaling**!
- **Stateful Architecture**: Servers maintain client session state in local RAM. Requires sticky sessions on load balancers, complicating failover and horizontal auto-scaling.

Key Takeaway: Architect application web tiers to be 100% stateless, storing user session state in distributed caches like Redis.

Question 8

What is a Single Point of Failure (SPOF) and how do redundant components mitigate risk?

Accepted Answer

A **Single Point of Failure (SPOF)** is any component in a system whose individual failure will cause the entire system or application to crash:

### Eliminating SPOFs Across System Layers:
1. **DNS Layer**: Use redundant multi-provider Anycast DNS.
2. **Load Balancer Layer**: Deploy dual active-passive load balancers with virtual IP failover (Keepalived / VRRP).
3. **Application Tier**: Maintain an auto-scaling group across multiple Availability Zones (AZs).
4. **Database Tier**: Configure multi-AZ primary/standby database failover.

Key Takeaway: Identify and eliminate all Single Points of Failure using redundant components across multiple Availability Zones.

Question 9

How does DNS Resolution and Anycast Routing direct users to nearest servers?

Accepted Answer

**DNS (Domain Name System)** translates human-readable hostnames ('example.com') into machine-routable IP addresses ('203.0.113.19'):

### Resolution Steps:
1. Browser checks local cache $\rightarrow$ Recursive Resolver $\rightarrow$ Root Nameserver ('.') $\rightarrow$ TLD Nameserver ('.com') $\rightarrow$ Authoritative Nameserver.
2. **Anycast Routing**: Multiple global servers advertise the **exact same IP address** using BGP. Network routers automatically route the user's packet to the geographically closest server!

Key Takeaway: Use Anycast DNS to route global users to the nearest edge server with minimal latency.

Question 10

Why use Message Queues (RabbitMQ, SQS) to decouple background worker tasks?

Accepted Answer

**Message Queues** buffer task messages between producer web services and consumer worker background pools:

### Core Benefits:
1. **Decoupling**: Web servers accept user file uploads or order submissions instantly, enqueueing a background task and returning '202 Accepted'.
2. **Load Smoothing**: During traffic spikes, messages buffer safely in the queue without crashing backend worker servers.
3. **Fault Tolerance**: If a worker node crashes mid-task, the message remains in the queue to be retried by another worker.

Key Takeaway: Use message queues to handle asynchronous background tasks and buffer traffic spikes safely.

Question 11

What is Rate Limiting and how does it protect backend servers from traffic surges?

Accepted Answer

**Rate Limiting** caps the maximum number of requests a client IP or authenticated user can submit within a specified time window:

### Why Rate Limiting is Mandatory:
- Prevents Denial of Service (DoS) attacks and web scraping.
- Protects downstream databases from being overwhelmed during traffic spikes.
- Returns standard **'429 Too Many Requests'** HTTP status code with 'Retry-After' response headers.

Key Takeaway: Enforce rate limiting on all public API endpoints to protect backend infrastructure from DoS and traffic spikes.

Question 12

What is Object Blob Storage (Amazon S3) vs Block Storage vs File Storage?

Accepted Answer

Evaluating storage architectures for cloud applications:

- **Object Storage (Amazon S3)**: Stores unstructured data (images, videos, backups) as flat objects with metadata and unique HTTP URLs. Near-infinite scalability, highly durable ($99.999999999\%$).
- **Block Storage (AWS EBS)**: High-speed raw disk volumes mounted directly to a single server instance. Ideal for databases requiring low latency I/O.
- **File Storage (AWS EFS / NFS)**: Shared hierarchical network file system accessible concurrently by multiple server instances.

Key Takeaway: Store unstructured media files and static assets in S3 Object Storage rather than local web server disks.

Question 13

What are the architectural trade-offs between Monolithic and Microservice Architectures?

Accepted Answer

Evaluating application architecture paradigms:

| Attribute | Monolithic Architecture | Microservice Architecture |
|---|---|---|
| **Deployment** | Single deployment artifact (Easy initially) | Dozens of independently deployed services |
| **Team Autonomy** | Teams can bottleneck on shared codebase | Autonomous domain teams deploy independently |
| **Complexity** | Simple in-memory function calls; easy debugging | High complexity: network latency, distributed tracing |
| **Scaling** | Must scale entire monolith together | Scale specific bottleneck services independently |

Key Takeaway: Start with a well-structured modular monolith, decoupling into microservices only when organizational or scale bottlenecks emerge.

Question 14

What is the Publisher-Subscriber (Pub/Sub) pattern?

Accepted Answer

The **Publisher-Subscriber (Pub/Sub)** pattern is an asynchronous messaging pattern where message senders (**Publishers**) do not send messages directly to specific receivers:

### How Pub/Sub Works:
1. Publishers publish messages to named **Topics** on a Message Broker (Apache Kafka, RabbitMQ, Google Cloud Pub/Sub).
2. Multiple subscriber services subscribe to topics of interest.
3. **Fan-Out**: When a message is published, the broker automatically broadcasts a copy to ALL subscribed services concurrently!

Key Takeaway: Use Pub/Sub messaging to broadcast events to multiple downstream consumer services without coupling the producer.

Question 15

What is Consistent Hashing and why is it essential for distributed caching clusters?

Accepted Answer

Standard modulo hashing ('hash(key) % N') causes **99% of cached keys to remap** whenever a cache server node is added or removed from a cluster!

### Consistent Hashing Solution:
Maps both keys and server nodes onto a virtual **Hash Ring** ($0$ to $2^{32}-1$):
- Keys are assigned to the first server encountered moving clockwise on the ring.
- **Node Removal/Addition**: Adding or removing a server node remaps ONLY $1/N$ of keys, preventing massive cache invalidation storms!

Key Takeaway: Use Consistent Hashing in distributed cache clusters to ensure smooth node scaling with minimal key remapping.

Question 16

What is a Reverse Proxy (NGINX, HAProxy, Envoy) and how does it differ from a Forward Proxy?

Accepted Answer

Differentiating proxy server architectures:

- **Forward Proxy**: Sits in front of client browsers (e.g. corporate network proxy). Masks client IP addresses and enforces internet egress filtering.
- **Reverse Proxy (NGINX, Envoy, HAProxy)**: Sits in front of backend web servers. Intercepts incoming client requests to perform **SSL/TLS Termination**, **HTTP caching**, **Gzip compression**, and **Load Balancing**, hiding backend internal IP topology.

Key Takeaway: Deploy Reverse Proxies (NGINX/Envoy) at the perimeter for SSL termination, compression, and load balancing.

Question 17

When should you choose a Relational SQL database versus a NoSQL Document/Key-Value store?

Accepted Answer

Evaluating database paradigms:

| Criteria | Relational SQL (Postgres, MySQL) | NoSQL (MongoDB, DynamoDB, Redis) |
|---|---|---|
| **Data Structure** | Structured tables with fixed schemas & Foreign Keys | Unstructured / JSON Documents / Key-Value pairs |
| **ACID & Consistency** | Strict ACID transactions & strong consistency | Eventual consistency; high write throughput |
| **Scaling** | Vertical scaling (Scale up); Read Replicas | Horizontal scaling (Scale out sharding out of box) |
| **Best For** | Financial transactions, e-commerce orders, relational data | High-velocity logs, user session caches, real-time feeds |

Key Takeaway: Choose Relational SQL for complex ACID financial transactions, and NoSQL for high-throughput, horizontally scalable unstructured data.

Question 18

What is Latency vs Throughput and how do SLA/SLO performance targets work?

Accepted Answer

Measuring system performance parameters:

- **Latency**: The time taken to process a single request from client invocation to response receipt (e.g. $45	ext{ms}$).
- **Throughput**: The volume of work or requests the system can process per unit of time (e.g. $10,000	ext{ Requests Per Second - RPS}$). 
- **Percentiles ($p95, p99$)**: $p99$ latency represents the worst $1\%$ of requests. Never rely on average latency! 
- **SLO (Service Level Objective)**: Target performance bound (e.g. $p99 	ext{ Latency} < 200	ext{ms}$).

Key Takeaway: Target latency percentiles (p95, p99) rather than averages to ensure acceptable performance for all users.

Question 19

How do Heartbeat Health Checks detect failed server instances?

Accepted Answer

**Heartbeat Health Checks** allow load balancers and orchestrators (Kubernetes) to monitor the operational status of backend server instances:

### How Health Checks Work:
1. Load balancer sends periodic HTTP requests (e.g. 'GET /healthz') every 5 seconds to backend nodes.
2. If a node responds with '200 OK' $\rightarrow$ Node is healthy.
3. If a node fails $N$ consecutive health checks (or times out) $\rightarrow$ Node marked unhealthy and removed from active traffic routing!

Key Takeaway: Expose lightweight `/healthz` endpoints to allow load balancers to detect and automatically bypass unhealthy server instances.

Question 20

Why is Cache Invalidation considered one of the hardest problems in computer science?

Accepted Answer

Phil Karlton famously noted: *"There are only two hard things in Computer Science: cache invalidation and naming things."*

### Why Cache Invalidation is Difficult:
When data mutates in the primary database, all distributed cache copies must be updated or evicted immediately. If invalidation fails or experiences network lag, clients receive **stale data**.
- **Mitigations**: Set sensible Time-to-Live (TTL) expirations, and execute event-driven cache purges (via CDC or Pub/Sub) on data mutations.

Key Takeaway: Combine TTL expirations with event-driven cache purges to prevent stale data reads.

Question 21

Why is Database Connection Pooling required in high-concurrency systems?

Accepted Answer

Establishing a raw database connection requires costly TCP 3-way handshakes, TLS negotiation, and user authentication (~50ms overhead per connection):

### Connection Pool Benefits:
1. **Pre-Established Connections**: Maintains a warm pool of open, reusable database sockets.
2. **Resource Throttling**: Prevents incoming web traffic bursts from opening thousands of concurrent database connections and crashing DB memory!

Key Takeaway: Use database connection pools to eliminate connection setup latency and protect databases from connection exhaustion.

Question 22

Why is Idempotency critical in distributed payment and order processing systems?

Accepted Answer

In distributed systems, network requests can time out without the client knowing if the server processed the request. If the client retries the request, an un-idempotent system executes the action twice!

### Idempotency Solution:
An operation is **Idempotent** if executing it multiple times yields the **exact same result** as executing it once.
- *Implementation*: Clients send a unique 'Idempotency-Key' header with payment requests ('POST /charge'). The server tracks processed keys in Redis, returning cached responses for duplicate retries.

Key Takeaway: Enforce Idempotency Keys on all state-changing endpoints to protect against duplicate processing during client retries.

Question 23

How do Database Indexes speed up reads at the cost of write performance?

Accepted Answer

A **Database Index** is a secondary data structure (usually a B-Tree) that allows the database engine to locate target rows without scanning the entire table:

### Read vs Write Trade-Off:
- **Read Acceleration**: Reduces query lookups from an $O(N)$ full table scan to an $O(\log N)$ index seek.
- **Write Penalty**: Every 'INSERT', 'UPDATE', or 'DELETE' statement MUST update all secondary B-Tree indexes on the table, slowing down write throughput!
- *Rule*: Never index every column; create indexes based strictly on query access patterns.

Key Takeaway: Create secondary indexes selectively based on query filter access patterns to balance read acceleration against write penalties.

Question 24

What is Synchronous Blocking vs Asynchronous Non-Blocking execution?

Accepted Answer

Evaluating execution model concurrency paradigms:

- **Synchronous Execution**: Threads block and wait passively for operations (like disk I/O or network requests) to complete before executing subsequent lines of code.
- **Asynchronous Execution**: Threads delegate I/O tasks to the OS kernel or event loop and continue executing other work immediately. Callbacks or Promises trigger when the I/O completes, handling high concurrency with minimal threads (e.g. Node.js Event Loop).

Key Takeaway: Use asynchronous non-blocking execution models to achieve high concurrency throughput with minimal thread overhead.

Question 25

Why is Distributed Logging (ELK Stack, Grafana Loki) necessary for microservices?

Accepted Answer

In a microservices architecture running across hundreds of container instances, reading local log files on individual servers is impossible:

### Distributed Logging Architecture:
1. **Log Shippers (Filebeat/Vector)**: Stream stdout/stderr logs from container hosts.
2. **Log Indexer / Storage**: Aggregates and indexes log streams in a centralized search store (Elasticsearch or Grafana Loki).
3. **Visualization (Kibana/Grafana)**: Provides a single UI dashboard to search, filter, and trace log events across all microservices.

Key Takeaway: Aggregate microservice logs into a centralized indexing platform like ELK or Grafana Loki for multi-service debugging.

Question 26

What is the Circuit Breaker Pattern and how does it prevent cascading system failures?

Accepted Answer

The **Circuit Breaker Pattern** wraps remote network calls to prevent a failing downstream service from causing cascading failure across an entire system:

### 3 States:
1. 🟢 **Closed (Normal)**: Requests pass through to the downstream service.
2. 🔴 **Open (Failing)**: Downstream error threshold exceeded. Circuit trips open immediately; all subsequent calls fail fast or execute fallbacks without calling the failing service!
3. 🟡 **Half-Open (Testing)**: After a cooldown timer, limited trial requests test if the downstream service has recovered.

Key Takeaway: Wrap downstream network calls with Circuit Breakers to fail fast and prevent cascading microservice outages.

Question 27

How do you design a high-throughput URL Shortener (like Bitly)?

Accepted Answer

Designing a high-throughput URL Shortener service (e.g. Bitly):

### Key Components:
1. **Short Code Generation**: Convert auto-incrementing integer IDs into **Base62 strings** ('[0-9, a-z, A-Z]'). A 7-character Base62 string supports $62^7 \approx 3.5 	ext{ Trillion}$ unique short URLs!
2. **Redirect Types**:
   - **'HTTP 301 Permanent'**: Browser caches redirect locally (reduces server load, loses click analytics).
   - **'HTTP 302 Temporary'**: Browser requests short URL every time (enables click analytics tracking).
3. **Caching**: Cache top 20% hot short URLs in Redis.

Key Takeaway: Design URL shorteners by converting auto-increment IDs to Base62 strings and caching hot mappings in Redis.

Question 28

Compare Polling vs Long Polling vs WebSockets vs Server-Sent Events (SSE) for real-time UIs.

Accepted Answer

Evaluating real-time client-server communication technologies:

| Technology | Direction | Protocol | Ideal Use Case |
|---|---|---|---|
| **Short Polling** | Client $\rightarrow$ Server | HTTP | Low-frequency periodic updates |
| **Long Polling** | Client $\leftrightarrow$ Server | HTTP (Kept open) | Legacy push updates without WebSocket support |
| **WebSockets** | Bi-directional (Full-Duplex) | TCP ('ws://' / 'wss://') | Real-time chat, multiplayer gaming, collaborative editing |
| **Server-Sent Events (SSE)** | Server $\rightarrow$ Client (Uni-directional) | HTTP ('text/event-stream') | Live stock tickers, news feeds, LLM token streaming |

Key Takeaway: Use WebSockets for bi-directional real-time communication (chat), and SSE for uni-directional server streaming (stock tickers, LLMs).

Question 29

When and why should you Denormalize relational databases?

Accepted Answer

**Database Denormalization** is the intentional technique of adding redundant data fields to a normalized schema:

### Trade-Off:
- **Read Latency**: Eliminates expensive multi-table 'JOIN' operations by embedding pre-computed columns (e.g. storing 'user_name' directly inside the 'orders' table).
- **Write Penalty**: Updating 'user_name' requires mutating multiple tables simultaneously, increasing write maintenance complexity.
- *Rule*: Denormalize only when read latency on high-frequency queries is a critical bottleneck.

Key Takeaway: Denormalize relational tables selectively to optimize high-frequency read queries by eliminating multi-table JOINs.

Question 30

What is Graceful Degradation and how do static fallbacks preserve core UX?

Accepted Answer

**Graceful Degradation** is a resilience engineering principle ensuring that when non-essential subsystems fail or time out, the primary application remains operational:

### Practical Implementation:
If an e-commerce Product Page's AI Recommendation Microservice fails:
- **Brittle Failure**: Entire product page crashes with HTTP 500.
- **Graceful Degradation**: Catch the recommendation API failure, log the error, and render the product page with a static cached list of "Top Selling Items" instead!

Key Takeaway: Design applications with Graceful Degradation to ensure core user workflows remain functional during secondary subsystem outages.

Question 31

How does the Saga Pattern manage distributed transactions across microservices?

Accepted Answer

The **Saga Pattern** manages distributed transactions across independent microservices without holding database locks:

### Saga Mechanics:
A Saga executes a sequence of local transactions. Each local transaction updates a service database and emits an event to trigger the next step:
- **Choreography**: Microservices listen to events and execute steps independently.
- **Orchestration**: A central Saga Orchestrator coordinates transaction execution flow.
- **Compensating Actions**: If step 3 fails, the Saga executes rollback compensating actions in reverse order (e.g. 'RefundPayment' $\rightarrow$ 'CancelReservation').

Key Takeaway: Use the Saga Pattern with compensating actions to coordinate distributed microservice transactions eventually consistently.

Question 32

What is Event Sourcing and how does it pair with CQRS?

Accepted Answer

**Event Sourcing** and **CQRS** are architectural patterns that decouple write and read data operations:

- **Event Sourcing**: Stores state mutations as an append-only sequence of immutable events ('OrderCreated', 'PaymentReceived', 'OrderShipped'). Current state is derived by replaying events.
- **CQRS**: Separates the write model (**Commands**) from read models (**Queries**). Event projections update optimized read stores (Elasticsearch/Redis) asynchronously.

Key Takeaway: Pair Event Sourcing with CQRS to maintain complete auditability and optimize read and write models independently.

Question 33

How does Redis Cluster shard data using Hash Slots?

Accepted Answer

**Redis Cluster** distributes data across multiple Redis nodes automatically using **Hash Slots**:

### Architecture:
1. The keyspace is divided into **16,384 logical Hash Slots**.
2. Key slot assignment formula: $	ext{Slot} = 	ext{CRC16}(key) \pmod{16384}$.
3. Master nodes in the cluster own sub-ranges of the 16,384 slots.
4. **Hash Tags**: Enclosing part of a key in curly braces ('{user:100}:profile') forces related keys onto the exact same hash slot for multi-key operations!

Key Takeaway: Redis Cluster uses 16,384 Hash Slots to shard data evenly across master nodes with automatic failover.

Question 34

How do you design a scalable Notification System (push, email, SMS)?

Accepted Answer

Designing a global multi-channel Notification System (Push, Email, SMS):

### Key Components:
1. **Notification Router**: Validates payloads and checks user preference settings (e.g. Do Not Disturb hours).
2. **Priority Queues**: Separates high-priority notifications (MFA codes) from low-priority marketing emails in SQS/RabbitMQ.
3. **Provider Workers**: Interacts with third-party delivery gateways (Apple APNs, Google FCM, Twilio, SendGrid).
4. **Deduplication**: Uses Redis keys to prevent sending duplicate notifications during worker retries.

Key Takeaway: Design notification systems using priority queues and user preference filters to handle multi-channel delivery reliably.

Question 35

How do you design a Distributed Rate Limiter using Redis Lua Scripts?

Accepted Answer

Enforcing rate limits across a cluster of API Gateway nodes requires a shared distributed cache (Redis):

### Atomic Redis Lua Execution:
Checking and incrementing request counters must happen atomically to prevent race conditions across gateway replicas. Executing a **Redis Lua Script** guarantees that counter evaluation runs atomically on the Redis server!

Key Takeaway: Use atomic Redis Lua scripts to execute sliding window rate limiting across distributed API Gateway nodes without race conditions.

Question 36

How do Apache Kafka Partitions, Log Segments, and Consumer Groups scale message streaming?

Accepted Answer

**Apache Kafka** is a distributed, append-only event streaming platform:

### Scaling Mechanics:
1. **Topic Partitions**: Topics are divided into partitions distributed across brokers. Messages with the same key route to the same partition, guaranteeing **strict message ordering per partition**.
2. **Consumer Groups**: Multiple consumers share topic reading load. Kafka assigns each partition to exactly ONE consumer within a consumer group to parallelize consumption.

Key Takeaway: Design Kafka topics with message keys to guarantee per-partition ordering while scaling processing across consumer groups.

Question 37

How do you choose optimal Shard Keys for horizontal database partitioning?

Accepted Answer

Selecting a poor Shard Key causes data imbalance (**Hotspotting**) and forces queries to execute expensive **Scatter-Gather** operations across all shards:

### Shard Key Selection Rules:
1. **High Cardinality**: Choose keys with millions of unique values (e.g. 'user_id' or 'tenant_id').
2. **Even Distribution**: Avoid monotonically increasing keys (like auto-increment IDs or timestamps) that route all new writes to the highest shard.
3. **Query Co-location**: Choose keys used in frequent filter queries ('WHERE tenant_id = 5') to execute single-shard lookups.

Key Takeaway: Select high-cardinality shard keys that distribute data evenly and co-locate frequent queries to a single shard node.

Question 38

How does the Redlock Algorithm acquire distributed locks across multiple Redis instances?

Accepted Answer

The **Redlock Algorithm** acquires distributed locks across $N$ (typically 5) independent, un-replicated Redis master nodes:

### How Redlock Works:
1. Captures current timestamp $T_1$.
2. Attempts to acquire the lock sequentially on all 5 Redis instances with a short timeout.
3. If the client acquires locks from a **majority quorum** ($\ge 3$ instances) and total elapsed time $T_2 - T_1 < 	ext{Lock TTL}$, the lock is granted!
- *Fencing Tokens*: Pass monotonically increasing fencing tokens to storage resources to reject stale lock holders.

Key Takeaway: Use Redlock with fencing tokens to coordinate distributed locks across independent Redis master nodes safely.

Question 39

How do you architect Database Read/Write Splitting with Sticky Replica routing?

Accepted Answer

Architecting database read/write splitting routes 'INSERT/UPDATE' traffic to the Primary DB and 'SELECT' traffic to Read Replicas:

### Replication Lag Glitch & Sticky Fix:
- *Problem*: User updates profile name $\rightarrow$ Redirects to profile page $\rightarrow$ Reads from replica before replication completes $\rightarrow$ User sees old profile name!
- *Sticky Replica Routing*: When a user writes data, flag their session to route ALL subsequent reads to the **Primary DB for 5 seconds**, guaranteeing they read their own writes!

Key Takeaway: Use Sticky Replica routing to direct recent writers to the primary database, eliminating replication lag read glitches.

Question 40

What is the Backend-For-Frontend (BFF) Pattern and how does it optimize client APIs?

Accepted Answer

The **Backend-For-Frontend (BFF)** pattern creates dedicated API gateway services tailored specifically to the requirements of different client user interfaces:

### Benefits:
1. **Tailored Payloads**: Mobile BFF aggregates multiple downstream microservice calls and returns a trimmed, lightweight JSON payload to save mobile bandwidth.
2. **Independent Deployments**: Mobile and Web teams manage their own BFF gateways independently without bottlenecking on a central API team.

Key Takeaway: Deploy BFF gateways to provide client-optimized API endpoints and prevent monolithic API Gateway bottlenecks.

Question 41

How do you design a real-time Chat Application (like WhatsApp or Slack)?

Accepted Answer

Designing a high-concurrency real-time Chat Application (WhatsApp/Slack):

### Core Architecture:
1. **Connection Gateway**: Manages millions of long-lived **WebSocket** connections across server clusters.
2. **Presence & Routing**: Tracks online status in Redis ('user:100 -> gateway_node_3'). Directs messages to active WebSockets or pushes notifications for offline users.
3. **Message History**: Stores chat messages in an append-only NoSQL database (Cassandra / HBase) partitioned by 'chat_id'.

Key Takeaway: Design chat applications using WebSocket connection gateways, Redis presence tracking, and Cassandra message history.

Question 42

How does a Service Mesh (Istio, Linkerd) handle mTLS, traffic splitting, and telemetry?

Accepted Answer

A **Service Mesh** (Istio, Linkerd) manages microservice-to-microservice communication using lightweight **Envoy sidecar proxies** running alongside application containers:

### Core Capabilities:
1. **Mutual TLS (mTLS)**: Automatically encrypts and authenticates inter-service traffic with zero application code changes.
2. **Traffic Splitting**: Implements percentage-based canary routing ('90% v1, 10% v2').
3. **Observability**: Collects latency metrics and distributed traces transparently at the proxy layer.

Key Takeaway: Deploy a Service Mesh to offload mTLS encryption, canary traffic management, and distributed tracing from application code.

Question 43

How do you design a News Feed System (Push/Fan-out on Write vs Pull/Fan-out on Read)?

Accepted Answer

Designing a social media News Feed System (Facebook/Twitter):

### 2 Fan-out Strategies:
- **Fan-out on Write (Push)**: When a user posts, the system pushes post IDs directly into every follower's feed cache in Redis. Fast reads ($O(1)$), but fails for celebrities with 50 million followers!
- **Fan-out on Read (Pull)**: Followers fetch posts from followed accounts when opening the app. Fast writes, slow reads.
- **Hybrid Approach**: Use Fan-out on Write for regular users, and Fan-out on Read for celebrity accounts!

Key Takeaway: Use a hybrid fan-out model: push posts for regular users to Redis feed caches, and pull posts dynamically for high-follower celebrity accounts.

Question 44

How does OpenTelemetry collect trace spans across microservice boundaries?

Accepted Answer

**OpenTelemetry** standardizes distributed tracing context propagation across microservices:

### Context Propagation Workflow:
1. Originating service generates a global 128-bit **Trace ID** and 64-bit **Span ID**.
2. Injects W3C header into outbound HTTP requests: 'traceparent: 00-4bf92f3577b...-00f067aa0ba902b7-01'.
3. Downstream services extract the 'traceparent' header, attach their own child Span ID, and pass it along, allowing APMs (Jaeger, Datadog) to construct complete request timelines!

Key Takeaway: Propagate W3C traceparent headers across microservice calls to enable end-to-end distributed tracing visibility.

Question 45

How do you design a Video Streaming Platform (like YouTube or Netflix)?

Accepted Answer

Designing a global Video Streaming Platform (YouTube/Netflix):

### Processing Pipeline:
1. **Video Ingestion**: Raw video uploaded to S3 Object Storage via chunked multi-part upload.
2. **Transcoding Worker Pool**: Background workers split video into 10-second segments and transcode into multiple resolutions (1080p, 720p, 480p) using **HLS** or **DASH** protocols.
3. **CDN Delivery**: Delivers adaptive video chunks globally based on client network bandwidth.

Key Takeaway: Design video streaming platforms using background transcoding workers to generate adaptive HLS/DASH video chunks served via global CDNs.

Question 46

What is Change Data Capture (CDC) and how does Debezium stream database mutations?

Accepted Answer

**Change Data Capture (CDC)** streams database row mutations ('INSERT', 'UPDATE', 'DELETE') into event brokers (Kafka) by tailing the database's native transaction log (MySQL binlog / Postgres WAL):

### Advantages over DB Polling:
- **Zero Application Changes**: Captures DB mutations without application code changes.
- **Zero Query Overhead**: Tails log files on disk without executing heavy 'SELECT' queries on primary database tables.
- **Captures Deletes**: Reliable event detection for hard deletes.

Key Takeaway: Deploy Change Data Capture (CDC) with Debezium to stream database mutations into Kafka with zero performance impact on database query engines.

Question 47

What is the Cache Stampede (Thundering Herd) problem and how do you prevent it with Probabilistic Early Expiration?

Accepted Answer

A **Cache Stampede (Thundering Herd)** occurs when a heavily accessed hot cache key expires, causing thousands of concurrent user requests to hit the database simultaneously to recompute the key:

### Mitigation Strategies:
1. **Mutex Lock (Single-Flight)**: The first request acquires a lock to recompute the cache value; subsequent requests wait for the cache update.
2. **XFetch (Probabilistic Early Expiration)**: Randomly recomputes hot cache keys in the background shortly before actual TTL expiration based on access frequency!

Key Takeaway: Use Mutex Locks or Probabilistic Early Expiration (XFetch) to prevent Thundering Herd spikes on database servers during hot cache key expirations.

Question 48

How do you design a Distributed Web Crawler (like Google Bot)?

Accepted Answer

Designing a high-throughput Distributed Web Crawler (Google Bot):

### Architecture:
1. **URL Frontier**: Prioritized crawling queue enforcing domain **politeness delays** (e.g. max 1 request per second per host IP).
2. **HTML Fetchers**: Asynchronous HTTP workers executing page fetches.
3. **URL Deduplication**: Uses a **Bloom Filter** to verify if a discovered URL has already been crawled before enqueueing.
4. **Document Deduplication**: Computes **SimHash** distance to detect duplicate content across different URLs.

Key Takeaway: Design web crawlers using a URL Frontier for domain politeness and Bloom Filters for URL deduplication.

Question 49

What is a Bloom Filter and how does it provide fast space-efficient set membership checks?

Accepted Answer

A **Bloom Filter** is a space-efficient probabilistic data structure used to test whether an element is a member of a set:

### Core Properties:
- **No False Negatives**: If the Bloom Filter returns 'false' ("Element Not Present"), it is **100% guaranteed** not to be in the set!
- **Possible False Positives**: If it returns 'true', the element is *probably* in the set.
- *Memory Efficiency*: Uses a compact bit array with $k$ independent hash functions, testing set membership in $O(k)$ time using kilobytes of RAM for millions of items!

Key Takeaway: Use Bloom Filters to eliminate expensive database lookups for non-existent keys with zero false negatives.

Question 50

How do you design a Search Autocomplete / Typeahead System?

Accepted Answer

Designing a real-time Search Autocomplete / Typeahead System (Google Search):

### Key Components:
1. **Trie (Prefix Tree)**: Stores search terms in memory. Each node stores the **top 5 most frequent search terms** matching that prefix to return $O(1)$ lookups.
2. **Frequency Aggregation**: MapReduce / Flink jobs process raw search logs in background batches to update top-k Trie node frequencies.
3. **Client Optimization**: Debounces user keystrokes (200ms) and caches prefix results in browser/CDN.

Key Takeaway: Design autocomplete typeahead systems using memory-cached Trie data structures pre-populated with top-k prefix suggestions.

Question 51

How does Multi-Version Concurrency Control (MVCC) eliminate read-write locks in databases?

Accepted Answer

**Multi-Version Concurrency Control (MVCC)** enables relational databases (Postgres, InnoDB) to execute non-locking consistent reads where **"Readers do not block Writers, and Writers do not block Readers"**:

### How MVCC Works:
- When a row is updated, the database engine does NOT overwrite the original row in-place; it creates a **new row version** and appends the old version to the **Undo Log**.
- Concurrent read queries inspect a snapshot matching their transaction start timestamp, reading historical row versions without blocking active write transactions!

Key Takeaway: MVCC uses row versioning and Undo Logs so read queries execute concurrently without waiting for write locks.

Question 52

What is the Gossip Protocol and how does it maintain cluster membership in Cassandra?

Accepted Answer

The **Gossip Protocol** is a decentralized peer-to-peer communication protocol used in distributed databases (Apache Cassandra) to maintain cluster membership and detect node failures:

### How Gossip Works:
1. Every second, each cluster node selects a random neighbor node and exchanges state data.
2. State changes (node additions, crashes, schema updates) spread exponentially across the entire cluster in $O(\log N)$ time.
3. **Failure Detector**: Uses $\Phi$-Accrual Failure Detector to evaluate node responsiveness adaptively.

Key Takeaway: Use the Gossip Protocol for decentralized peer-to-peer state propagation and failure detection in large database clusters.

Question 53

How do you design a Location-Based Ride Sharing Service (like Uber or Lyft)?

Accepted Answer

Designing a real-time Location-Based Ride Sharing Service (Uber/Lyft):

### Core Architecture:
1. **Geospatial Indexing**: Divides global geography into discrete cells using **Uber H3 Hexagonal Spatial Index** or **Geohash**.
2. **Location Ingestion**: Drivers stream coordinates every 4 seconds over WebSockets into Redis Geospatial indexes ('GEOADD').
3. **Matching Engine**: Queries nearest available drivers in adjacent H3 cells ('GEORADIUS'), matching drivers to riders in $O(1)$ time.

Key Takeaway: Design location-based services using geospatial spatial indexes (Geohash/H3) and Redis to query nearby entities efficiently.

Question 54

What are Quorum Reads and Writes ($R + W > N$) in distributed databases?

Accepted Answer

In distributed masterless databases (Cassandra), consistency is tunable using **Quorum Reads and Writes**:

### Quorum Formula:
- **$N$**: Replication Factor (Total node copies).
- **$W$**: Write Quorum (Number of nodes that must acknowledge a write).
- **$R$**: Read Quorum (Number of nodes responding to a read).
- **Strong Consistency Condition**: If **$R + W > N$**, the read and write quorums overlap on at least 1 node, guaranteeing the client always reads the latest written value!

Key Takeaway: Configure R + W > N in distributed databases to achieve Strong Consistency across quorum node overlaps.

Question 55

What is Write Amplification in Log-Structured Merge (LSM) Trees?

Accepted Answer

**Log-Structured Merge (LSM) Trees** optimize write performance by buffering writes in an in-memory **MemTable** and flushing them sequentially to **SSTables** on disk:

### Write Amplification:
- Occurs when data is written to disk multiple times due to background **SSTable Compaction** merges.
- **Write Amplification Factor (WAF)**: Ratio of total bytes written to underlying storage vs bytes written by client. High WAF wears out SSD flash memory and consumes disk I/O bandwidth!

Key Takeaway: LSM-Trees provide fast sequential writes, but background compaction causes Write Amplification that must be monitored.

Question 56

How do you design a Distributed Key-Value Store (like DynamoDB or Cassandra)?

Accepted Answer

Designing a high-throughput Distributed Key-Value Store (DynamoDB/Cassandra):

### Architectural Building Blocks:
1. **Data Partitioning**: Consistent Hashing Ring with Virtual Nodes.
2. **Storage Engine**: LSM-Tree (MemTable + SSTables) for high-speed sequential writes.
3. **Cluster Membership**: Gossip Protocol for node discovery.
4. **Conflict Resolution**: Vector Clocks or Last-Write-Wins (LWW) timestamp ordering.
5. **Replication**: Tunable Quorum Reads and Writes ($R + W > N$).

Key Takeaway: Design distributed key-value stores by integrating Consistent Hashing, LSM-Trees, Gossip protocol, and Quorum consistency.

Question 57

How do you handle Stream Backpressure when data producers overwhelm data consumers?

Accepted Answer

**Backpressure** occurs when a high-speed data Producer emits events faster than a downstream Consumer can process them:

### 3 Handling Strategies:
1. **Buffering**: Queue incoming messages up to a memory threshold (risk of OOM crashes under sustained spikes).
2. **Drop / Shedming**: Drop excess messages or apply sampling (acceptable for non-critical telemetry logs).
3. **Pull-Based Flow Control (Reactive Streams)**: Consumer explicitly requests chunk capacity ('subscription.request(100)'), forcing the Producer to pause emission until requested!

Key Takeaway: Use pull-based backpressure mechanisms to prevent fast producers from exhausting consumer memory resources.

Question 58

What is the Two-Phase Commit (2PC) protocol and why does it suffer from blocking risks?

Accepted Answer

The **Two-Phase Commit (2PC)** protocol coordinates atomic transactions across multiple distributed database nodes:

### 2 Phases:
1. **Phase 1 (Prepare)**: Coordinator asks all participant nodes if they can commit. Participants acquire locks and vote 'YES' or 'NO'.
2. **Phase 2 (Commit/Abort)**: If all vote 'YES', Coordinator commands all nodes to 'COMMIT'. If any vote 'NO', Coordinator commands 'ABORT'.
- ⚠️ **Blocking Risk**: If the Coordinator crashes during Phase 2, participant nodes remain indefinitely blocked holding database locks!

Key Takeaway: Avoid 2PC for high-throughput microservices due to coordinator blocking risks; prefer eventual consistency Saga patterns.

Question 59

How do you design a Time-Series Metrics Collection System (like Prometheus)?

Accepted Answer

Designing a scalable Time-Series Metrics Collection System (Prometheus/Grafana):

### Architecture:
1. **Metrics Scraping (Pull Model)**: Server periodically fetches '/metrics' HTTP endpoints from target application instances.
2. **Time-Series Engine (TSDB)**: Uses **Gorilla Compression** to compress timestamped float values, achieving $10	imes$ memory reduction.
3. **Alert Manager**: Evaluates PromQL alerting rules and triggers PagerDuty/Slack notifications.

Key Takeaway: Design time-series metrics collectors using pull-based scraping and Gorilla compression for high-density timestamped storage.

Question 60

What is the Raft Consensus Algorithm and how does it compare to Paxos?

Accepted Answer

**Raft** is a distributed consensus algorithm designed to be understandable and equivalent to Multi-Paxos in fault tolerance:

### 3 Decomposed Sub-problems:
1. **Leader Election**: Uses randomized election timeouts to elect a single Leader node per Term.
2. **Log Replication**: Leader accepts client commands, appends them to its log, and replicates log entries to Followers.
3. **Safety**: Log entries are committed only after being replicated to a **majority quorum** ($N/2 + 1$) of nodes.

Key Takeaway: Raft achieves distributed consensus by electing a strong leader to manage log replication across a majority quorum.

Question 61

Compare Blue-Green Deployments vs Canary Deployments vs Rolling Releases.

Accepted Answer

Evaluating deployment release strategies:

| Strategy | Traffic Routing Mechanism | Rollback Speed | Hardware Cost |
|---|---|---|---|
| **Blue-Green** | Router switches 100% traffic from Blue to Green | Instant (Switch router back) | High (200% capacity needed) |
| **Canary** | Route 5% traffic to new version; gradually scale to 100% | Instant (Route 100% to stable) | Low to Moderate |
| **Rolling Update** | Replaces old instances with new instances 1-by-1 | Slow (Rollback instances 1-by-1) | Low (100% capacity) |

Key Takeaway: Use Canary deployments to validate new software releases with a small traffic sample before full rollout.

Question 62

How does the Leaky Bucket algorithm smooth traffic spikes in API Gateways?

Accepted Answer

The **Leaky Bucket Algorithm** processes bursty incoming traffic to produce a smooth, constant output rate:

### How It Works:
1. Incoming requests enter a FIFO queue (the "bucket").
2. Requests leak out of the bucket at a **fixed, constant rate** (e.g. 10 requests per second).
3. If the bucket overflows its maximum queue capacity, excess incoming requests are immediately rejected with '429 Too Many Requests'.

Key Takeaway: Use the Leaky Bucket algorithm in API Gateways when downstream services require a smooth, non-bursty traffic flow.

Question 63

Compare Cache Eviction Policies: Least Recently Used (LRU) vs Least Frequently Used (LFU) vs ARC.

Accepted Answer

Evaluating cache memory eviction algorithms:

- **LRU (Least Recently Used)**: Evicts the key that has not been accessed for the longest duration. Implemented via HashMap + Doubly LinkedList in $O(1)$ time.
- **LFU (Least Frequently Used)**: Evicts the key with the lowest total hit frequency count. Useful for long-term hot key caching.
- **ARC (Adaptive Replacement Cache)**: Dynamically tunes balance between LRU and LFU based on recent workload patterns.

Key Takeaway: Use LRU for general-purpose cache eviction, and LFU when historical frequency indicates long-term item utility.

Question 64

How does Service Discovery (HashiCorp Consul, Netflix Eureka) locate dynamic microservice instances?

Accepted Answer

In auto-scaling cloud environments, microservice container IP addresses change continuously. **Service Discovery** tracks dynamic instance locations:

### 2 Discovery Patterns:
1. **Client-Side Discovery**: Client queries the **Service Registry** (Consul/Eureka) directly to fetch active node IPs and executes load balancing locally.
2. **Server-Side Discovery**: Client sends requests to a Router/Load Balancer. The router queries the Service Registry and forwards traffic to an active node IP.

Key Takeaway: Use Service Discovery to map microservice names to dynamic container IP addresses automatically.

Take System Design & Architecture Skill Assessment Quiz

Showing 100 Questions

1. Explain the CAP Theorem and PACELC Theorem with real-world database examples.

PACELC Theorem:

2. What is Vertical Scaling (Scale Up) vs Horizontal Scaling (Scale Out)?

3. How do Load Balancers distribute traffic (Round Robin, Least Connections, IP Hash)?

4. What is a Content Delivery Network (CDN) and how does Edge Caching reduce latency?

5. What are Caching Strategies (Cache-Aside, Read-Through, Write-Through, Write-Back)?

6. What are Database Read Replicas and Data Sharding?

7. What is Stateless vs Stateful Service Architecture?

8. What is a Single Point of Failure (SPOF) and how do redundant components mitigate risk?

9. How does DNS Resolution and Anycast Routing direct users to nearest servers?

10. Why use Message Queues (RabbitMQ, SQS) to decouple background worker tasks?

11. What is Rate Limiting and how does it protect backend servers from traffic surges?

12. What is Object Blob Storage (Amazon S3) vs Block Storage vs File Storage?

13. What are the architectural trade-offs between Monolithic and Microservice Architectures?

14. What is the Publisher-Subscriber (Pub/Sub) pattern?

15. What is Consistent Hashing and why is it essential for distributed caching clusters?

16. What is a Reverse Proxy (NGINX, HAProxy, Envoy) and how does it differ from a Forward Proxy?

17. When should you choose a Relational SQL database versus a NoSQL Document/Key-Value store?

18. What is Latency vs Throughput and how do SLA/SLO performance targets work?

19. How do Heartbeat Health Checks detect failed server instances?

20. Why is Cache Invalidation considered one of the hardest problems in computer science?

21. Why is Database Connection Pooling required in high-concurrency systems?

22. Why is Idempotency critical in distributed payment and order processing systems?

23. How do Database Indexes speed up reads at the cost of write performance?

24. What is Synchronous Blocking vs Asynchronous Non-Blocking execution?

25. Why is Distributed Logging (ELK Stack, Grafana Loki) necessary for microservices?

26. What is the Circuit Breaker Pattern and how does it prevent cascading system failures?

27. How do you design a high-throughput URL Shortener (like Bitly)?

28. Compare Polling vs Long Polling vs WebSockets vs Server-Sent Events (SSE) for real-time UIs.

29. When and why should you Denormalize relational databases?

30. What is Graceful Degradation and how do static fallbacks preserve core UX?

31. How does the Saga Pattern manage distributed transactions across microservices?

32. What is Event Sourcing and how does it pair with CQRS?

33. How does Redis Cluster shard data using Hash Slots?

34. How do you design a scalable Notification System (push, email, SMS)?

35. How do you design a Distributed Rate Limiter using Redis Lua Scripts?

36. How do Apache Kafka Partitions, Log Segments, and Consumer Groups scale message streaming?

37. How do you choose optimal Shard Keys for horizontal database partitioning?

38. How does the Redlock Algorithm acquire distributed locks across multiple Redis instances?

39. How do you architect Database Read/Write Splitting with Sticky Replica routing?

40. What is the Backend-For-Frontend (BFF) Pattern and how does it optimize client APIs?

41. How do you design a real-time Chat Application (like WhatsApp or Slack)?

42. How does a Service Mesh (Istio, Linkerd) handle mTLS, traffic splitting, and telemetry?

43. How do you design a News Feed System (Push/Fan-out on Write vs Pull/Fan-out on Read)?

44. How does OpenTelemetry collect trace spans across microservice boundaries?

45. How do you design a Video Streaming Platform (like YouTube or Netflix)?

46. What is Change Data Capture (CDC) and how does Debezium stream database mutations?

47. What is the Cache Stampede (Thundering Herd) problem and how do you prevent it with Probabilistic Early Expiration?

48. How do you design a Distributed Web Crawler (like Google Bot)?

49. What is a Bloom Filter and how does it provide fast space-efficient set membership checks?

50. How do you design a Search Autocomplete / Typeahead System?

51. How does Multi-Version Concurrency Control (MVCC) eliminate read-write locks in databases?

52. What is the Gossip Protocol and how does it maintain cluster membership in Cassandra?

53. How do you design a Location-Based Ride Sharing Service (like Uber or Lyft)?

54. What are Quorum Reads and Writes ($R + W > N$) in distributed databases?

55. What is Write Amplification in Log-Structured Merge (LSM) Trees?

56. How do you design a Distributed Key-Value Store (like DynamoDB or Cassandra)?

57. How do you handle Stream Backpressure when data producers overwhelm data consumers?

58. What is the Two-Phase Commit (2PC) protocol and why does it suffer from blocking risks?

59. How do you design a Time-Series Metrics Collection System (like Prometheus)?

60. What is the Raft Consensus Algorithm and how does it compare to Paxos?

61. Compare Blue-Green Deployments vs Canary Deployments vs Rolling Releases.

62. How does the Leaky Bucket algorithm smooth traffic spikes in API Gateways?

63. Compare Cache Eviction Policies: Least Recently Used (LRU) vs Least Frequently Used (LFU) vs ARC.

64. How does Service Discovery (HashiCorp Consul, Netflix Eureka) locate dynamic microservice instances?

65. What is Resharding and how do you rebalance database shards without system downtime?

66. How do you handle Eventual Consistency Lag in CQRS Read Models?

67. What is a Write-Ahead Log (WAL) and how does it guarantee database crash recovery?

68. What are Fencing Tokens and why are they necessary in distributed locking?

69. How do Vector Clocks detect concurrent write conflicts in masterless databases?

70. How do Cache-Control directives and Surrogate Keys (Cache-Tags) control CDN purging?

71. How do you design a Global Code Deployment System (like GitHub / Meta Deployment Pipeline)?

72. What is Tail Latency Amplification and how do Hedged Requests mitigate high p99 latency?

73. How do you implement Dynamic Load Shedding based on CPU utilization and queue delay?

74. How do you design a Real-Time Collaborative Editor (like Figma or Google Docs)?

75. How does the HyperLogLog (HLL) algorithm estimate distinct count cardinality in $O(1)$ memory?

76. How do you design a High-Throughput Ad Click Tracking System (millions of events/sec)?

77. How does io_uring revolutionize asynchronous I/O in modern Linux high-performance servers?