How do you choose between SQL and NoSQL databases?

Choose SQL (PostgreSQL, MySQL) for structured data requiring ACID transactions, complex JOINs, and strict schema enforcement. Choose NoSQL (MongoDB, DynamoDB, Cassandra) for flexible schemas, massive horizontal scale, high write throughput, and eventual consistency workloads.

When should you choose Vertical Scaling vs Horizontal Scaling?

Start with vertical scaling (adding CPU/RAM to one server) for simplicity. Transition to horizontal scaling (adding more servers) when hardware limits are reached, cost curves become prohibitive, or high availability is required. Horizontal scaling introduces distributed system complexity.

What is the difference between Sharding, Partitioning, and Indexing?

Indexing speeds up read queries within a single table using B-Tree or Hash structures. Partitioning splits a single table into logical physical chunks within one database instance. Sharding distributes rows across multiple distinct database servers using a shard key, scaling write throughput and storage.

How do you scale WebSockets to millions of concurrent connections?

Increase Linux file descriptor limits, use Layer 4 load balancing with sticky sessions, and implement a Redis Pub/Sub backplane so any WebSocket server can relay messages to clients connected to other servers. Pattern: Client → HAProxy → WS Servers ↔ Redis Pub/Sub.

What is the difference between LSI and GSI in DynamoDB?

A Local Secondary Index (LSI) shares the same partition key as the base table but uses a different sort key. It is limited to 10GB per item collection and supports strong consistency. A Global Secondary Index (GSI) uses a completely different partition key, spans all partitions, supports only eventual consistency, and has its own dedicated throughput capacity.

Which database should I use for transactions, user profiles, logs, and analytics?

Use PostgreSQL for financial transactions (ACID compliance). Use MongoDB for user profiles (flexible JSON). Use Cassandra for logs and high-throughput writes (LSM tree). Use Apache Druid for real-time analytics (columnar storage). Use Elasticsearch for search and catalog (inverted index). Use Redis for sessions and caching (in-memory).

How does Consistent Hashing work?

Consistent hashing maps both servers and keys onto a circular ring. A key routes clockwise to the nearest server. When a node is added or removed, only 1/N keys need to migrate (vs nearly 100% in modulo hashing). Virtual nodes (100-200 per server) ensure even distribution and prevent hotspots.

How do you design a distributed rate limiter?

Use a Token Bucket algorithm for burst-friendly limiting. For distributed enforcement across multiple API gateway instances, use Redis with Lua scripts to atomically evaluate and increment counters, preventing race conditions (dirty reads) where concurrent requests could bypass the limit.

How does the Raft consensus algorithm guarantee Leader Election and Log Replication? — System Design Interview Answer & Trade-offs

Architectural Breakdown & AnalysisFAANG Aligned

In distributed databases, maintaining a consistent, replicated state machine across unreliable network nodes requires a consensus algorithm. While Paxos was historically dominant, Raft is designed for understandability and powers modern infrastructure like etcd (Kubernetes), Consul, and Kafka KRaft.\n\n### 1. The Three Node Roles\nAt any instant, a Raft node operates in one of three states:\n* Leader: Handles all client read/write requests, coordinates log replication, and broadcasts heartbeats.\n* Follower: Passive state; responds to leader RPCs and heartbeat pulses.\n* Candidate: Transitions here if leader heartbeats cease; requests votes to become the new leader.\n\n### 2. Leader Election & Randomized Timeouts\n1. Heartbeat & Election Timeout: The leader periodically broadcasts heartbeats (AppendEntries RPCs with empty payload). Followers expect a heartbeat within a randomized window (e.g., 150ms to 300ms).\n2. Candidate Transition: If a follower's election timer expires without a heartbeat, it increments the term number, votes for itself, and broadcasts RequestVote RPCs.\n3. Quorum Majority: A candidate becomes leader as soon as it secures votes from a strict majority of nodes ($\lfloor N/2 \rfloor + 1$). In a 5-node cluster, 3 votes are required.\n4. Split-Vote Prevention: Randomizing the election timeout prevents two candidates from starting elections at the exact same millisecond and splitting the vote.\n\n### 3. Log Replication & Commit Safety\n* When a client sends a write to the leader, the leader appends it to its local log.\n* The leader replicates the entry to followers via AppendEntries RPCs.\n* Once a majority of followers acknowledge writing the entry to disk, the leader marks the entry Committed, applies it to its local state machine, and replies to the client.\n* Log Matching Invariant: If two logs contain an entry with the same index and term, they are guaranteed to be identical up to that index.\n\n### Key Architectural Comparison\n| Consensus Dimension | Raft Protocol | Two-Phase Commit (2PC) | Paxos Protocol |

:---	:---	:---	:---
Leader Model	Strong, authoritative Leader	Centralized Coordinator	Dual/Multi-Proposer support
Complexity	Modular (Election separated from Replication)	Simple but blocking	Extremely complex edge states

How does the Raft consensus algorithm guarantee Leader Election and Log Replication?

Continue Learning on Being SDE