Always profile before optimizing. The bottleneck could be inefficient queries, memory leaks, or missing indexes. Scaling without understanding the problem wastes resources.

Without an idempotency key, the server has no way to know this is a retry. It processes the request again, potentially double-charging. Idempotency keys are essential for payment systems.

Full-text search on 10M rows in a relational DB is slow by design. Elasticsearch (or similar) is optimized for search with inverted indexes. This is the right tool for the job.

With modulo hashing, (key % 5) != (key % 6) for about 83% of keys. Only ~17% happen to map to the same node. This is why consistent hashing (which only moves ~1/N keys) is preferred.

Per-user rate limiting doesn't protect against distributed attacks. With 1M IPs each allowed 100 req/s, the aggregate could be massive. You need IP reputation, CAPTCHA, or global rate limits.

This is time-series user data (100B records). Cassandra excels at high write throughput, time-series data, and scales horizontally. User_id as partition key keeps user data together.

gRPC uses Protocol Buffers (binary, smaller than JSON) and enforces schemas at compile time. It's significantly faster for internal services where human readability isn't needed.

WebSockets provide persistent, bidirectional, low-latency connections - perfect for real-time location updates. Polling wastes bandwidth, SSE is unidirectional.

Twitter uses a hybrid: fan-out on write for normal users (pre-compute timelines), fan-out on read for celebrity accounts (too many followers to write to). This balances write amplification and read latency.

Financial systems need exactly-once semantics to prevent lost or duplicate transactions. This requires synchronous replication (wait for writes to multiple nodes) and idempotency.

Tokyo to Virginia is ~11,000 km. Light travels at ~200,000 km/s in fiber. Round trip: 22,000 / 200,000 = 110ms minimum. You can't beat physics - you need edge servers in Tokyo.

For read-heavy workloads, caching (Redis/Memcached) gives the biggest bang for buck. Cache hits avoid the database entirely. Replicas help too but cache is faster and cheaper.

Circuit breakers prevent cascading failures. When checkout fails, the circuit 'opens' and returns fast errors instead of timing out. This protects upstream services and lets users keep browsing.

1M images × 30 sec = 30M seconds of work per day. Day has 86,400 seconds. Workers needed: 30M / 86,400 ≈ 347. Round up to ~350 workers. This is back-of-envelope estimation in action!

The Architect's Framework: (1) Clarify requirements first - you can't design what you don't understand. (2) Estimate scale to inform decisions. (3) Design the architecture. (4) Deep-dive into critical areas.