System Design Tradeoffs
SQL vs NoSQL, WebSockets vs SSE, Consistency patterns, Sharding strategies
Technical Reference & Key Concepts
**SQL vs NoSQL** - **SQL:** ACID compliance, structured data, complex joins. Tradeoff: Harder to scale horizontally. - **NoSQL:** Flexible schema, high write throughput, easy horizontal scaling. Tradeoff: Eventual consistency, limited joins. **Long Polling vs WebSockets vs SSE** - **WebSockets:** Persistent bi-directional. Good for high-frequency real-time. Tradeoff: Stateful, harder to load balance. - **Long Polling:** Server holds request until data ready. Simpler infra. Tradeoff: Higher HTTP overhead. - **SSE (Server-Sent Events):** One-direction server->client over HTTP. Simpler than WS for streaming. Tradeoff: No client->server messaging. **Consistency Patterns** - **Strong:** All nodes see same data at all times. Tradeoff: Higher latency, lower availability (CP in CAP). - **Eventual:** Replicas converge over time. Tradeoff: Stale reads, higher availability (AP in CAP). - **Causal:** Causally related ops seen in order. Good balance for many apps. **Sharding Strategies** - **Hash-based:** Consistent hashing on shard key. Even distribution, but resharding is painful. - **Range-based:** Partition by key range (e.g., user_id 1-1M). Good for range queries, but can create hot spots. - **Directory-based:** Lookup service maps key->shard. Flexible but adds latency and SPOF risk.
Practice discussing these concepts out loud in live voice drills on GitGrilled.