Module 1: Introduction to Distributed Systems
What is a Distributed System?
A distributed system is a collection of independent computers that appears to its users as a single coherent system.
┌─────────────────────────────────────────────────────────────────┐ │ DISTRIBUTED SYSTEM │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Node A │ │ Node B │ │ Node C │ │ │ │ (NYC) │ │ (London)│ │ (Tokyo) │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ └───────────────┼───────────────┘ │ │ │ │ │ ┌────┴────┐ │ │ │ Network │ │ │ └────┬────┘ │ │ │ │ │ ┌────┴────┐ │ │ │ User │ │ │ │ (Sees │ │ │ │ ONE │ │ │ │ System) │ │ │ └─────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘
Key Characteristics
- Concurrency: Components execute simultaneously
- No Global Clock: Each node has its own clock
- Independent Failures: Components can fail independently
- Message Passing: Communication through network messages
Why Distributed Systems?
1. Scalability
┌─────────────────────────────────────────────────────────────────┐ │ SCALING COMPARISON │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ VERTICAL SCALING (Scale Up) HORIZONTAL SCALING (Out) │ │ ┌─────────────────────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ BIG SERVER │ │ S1 │ │ S2 │ │ S3 │ │ │ │ │ │ │ │ │ │ │ │ │ │ • 128 cores │ └─────┘ └─────┘ └─────┘ │ │ │ • 1TB RAM │ │ │ │ • 100TB SSD │ • Add more machines │ │ │ │ • Linear cost scaling │ │ └─────────────────────┘ • No single point of │ │ failure │ │ Limits: │ │ • Hardware ceiling Challenges: │ │ • Single point of failure • Coordination │ │ • Expensive • Data consistency │ │ • Downtime for upgrades • Network failures │ │ │ └─────────────────────────────────────────────────────────────────┘
2. Fault Tolerance
┌─────────────────────────────────────────────────────────────────┐ │ FAULT TOLERANCE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Single Server: Distributed: │ │ ┌─────────────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │ Server │ │ S1 │ │ S2 │ │ S3 │ │ │ │ │ ─── CRASH ───► │ ✓ │ │ ✓ │ │ ✗ │ │ │ │ ✗ │ └─────┘ └─────┘ └─────┘ │ │ └─────────────┘ │ │ Service: DOWN Service: RUNNING │ │ (2 of 3 nodes healthy) │ │ │ │ Redundancy enables: │ │ • Survive hardware failures │ │ • Survive network partitions │ │ • Zero-downtime deployments │ │ • Geographic disaster recovery │ │ │ └─────────────────────────────────────────────────────────────────┘
3. Latency Reduction
┌─────────────────────────────────────────────────────────────────┐ │ GEOGRAPHIC DISTRIBUTION │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Speed of light in fiber: ~200,000 km/s │ │ NYC to Tokyo: ~10,800 km │ │ Minimum RTT: ~108ms (physics limit!) │ │ │ │ Single Datacenter (US-East): │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ User in Tokyo ──── 108ms ────► US-East Server │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Distributed (Multi-Region): │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ User in Tokyo ──── 5ms ────► Tokyo Server │ │ │ │ User in NYC ────── 5ms ────► US-East Server │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Result: 20x latency improvement for global users! │ │ │ └─────────────────────────────────────────────────────────────────┘
Types of Distributed Systems
1. Client-Server
┌─────────────────────────────────────────────────────────────────┐ │ CLIENT-SERVER │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Clients Server │ │ ┌─────────────┐ ┌─────────────┐ │ │ │ Browser │ ──── HTTP ────► │ Web App │ │ │ └─────────────┘ │ │ │ │ ┌─────────────┐ │ • Handles │ │ │ │ Mobile App │ ──── HTTP ────► │ all │ │ │ └─────────────┘ │ logic │ │ │ ┌─────────────┐ │ │ │ │ │ CLI Tool │ ──── HTTP ────► │ • Single │ │ │ └─────────────┘ │ source │ │ │ │ of truth │ │ │ └─────────────┘ │ │ │ │ Examples: Traditional web apps, REST APIs │ │ Pros: Simple, centralized control │ │ Cons: Single point of failure, scalability limits │ │ │ └─────────────────────────────────────────────────────────────────┘
2. Peer-to-Peer (P2P)
┌─────────────────────────────────────────────────────────────────┐ │ PEER-TO-PEER │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────┐ │ │ │ Peer A │◄───────────┐ │ │ └────┬────┘ │ │ │ │ │ │ │ ▼ │ │ │ ┌─────────┐ ┌────┴────┐ │ │ │ Peer B │◄─────►│ Peer D │ │ │ └────┬────┘ └────┬────┘ │ │ │ │ │ │ ▼ │ │ │ ┌─────────┐ │ │ │ │ Peer C │◄───────────┘ │ │ └─────────┘ │ │ │ │ Every node is both client AND server │ │ │ │ Examples: BitTorrent, Bitcoin, IPFS │ │ Pros: No single point of failure, scales naturally │ │ Cons: Complex coordination, consistency challenges │ │ │ └─────────────────────────────────────────────────────────────────┘
3. Microservices
┌─────────────────────────────────────────────────────────────────┐ │ MICROSERVICES │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ │ │ │ API Gateway │ │ │ └──────┬──────┘ │ │ │ │ │ ┌────┴────┬────────┬────────┬────────┐ │ │ ▼ ▼ ▼ ▼ ▼ │ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │ User │ │Order │ │ Pay │ │Notif │ │Search│ │ │ │ Svc │ │ Svc │ │ Svc │ │ Svc │ │ Svc │ │ │ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ │ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │ DB │ │ DB │ │ DB │ │Redis │ │Elastic│ │ │ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ │ │ │ │ Each service: Independent, deployable, scalable │ │ Examples: Netflix, Amazon, Uber │ │ │ └─────────────────────────────────────────────────────────────────┘
The 8 Fallacies of Distributed Computing
Peter Deutsch (and others at Sun Microsystems) identified these false assumptions that developers make:
Fallacy 1: The Network is Reliable
┌─────────────────────────────────────────────────────────────────┐ │ FALLACY 1: THE NETWORK IS RELIABLE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ What developers assume: │ │ ┌─────────┐ ──── request ────► ┌─────────┐ │ │ │ Service │ ◄─── response ──── │ Service │ │ │ │ A │ (always) │ B │ │ │ └─────────┘ └─────────┘ │ │ │ │ Reality: │ │ ┌─────────┐ ──── request ──✗ ┌─────────┐ │ │ │ Service │ ◄─── response ──✗ │ Service │ │ │ │ A │ (sometimes) │ B │ │ │ └─────────┘ └─────────┘ │ │ │ │ Failure modes: │ │ • Packets dropped (congestion, buffer overflow) │ │ • Connection timeout │ │ • Network partition │ │ • DNS failure │ │ • TLS handshake failure │ │ │ │ Solutions: │ │ • Retry with exponential backoff │ │ • Circuit breakers │ │ • Timeouts on ALL network calls │ │ • Idempotent operations │ │ • Queue-based async communication │ │ │ └─────────────────────────────────────────────────────────────────┘
Fallacy 2: Latency is Zero
┌─────────────────────────────────────────────────────────────────┐ │ FALLACY 2: LATENCY IS ZERO │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ LATENCY NUMBERS EVERY PROGRAMMER SHOULD KNOW: │ │ │ │ Operation Time │ │ ───────────────────────────────────────────────── │ │ L1 cache reference 0.5 ns │ │ L2 cache reference 7 ns │ │ Main memory reference 100 ns │ │ SSD random read 150,000 ns (150 μs) │ │ HDD seek 10,000,000 ns (10 ms) │ │ Same datacenter round trip 500,000 ns (0.5 ms) │ │ California to Netherlands 150,000,000 ns (150 ms) │ │ │ │ Impact of "just one more API call": │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Monolith: 1 function call = 10 ns │ │ │ │ Microservice: 1 API call = 1,000,000 ns (1 ms) │ │ │ │ │ │ │ │ That's 100,000x slower! │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Solutions: │ │ • Batch requests where possible │ │ • Use caching aggressively │ │ • Colocate services that communicate frequently │ │ • Async where real-time isn't needed │ │ • Consider service boundaries carefully │ │ │ └─────────────────────────────────────────────────────────────────┘
Fallacy 3: Bandwidth is Infinite
┌─────────────────────────────────────────────────────────────────┐ │ FALLACY 3: BANDWIDTH IS INFINITE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Bandwidth costs money and has limits: │ │ │ │ Cloud egress pricing (AWS): │ │ • First 10 TB/month: $0.09/GB │ │ • 10-50 TB/month: $0.085/GB │ │ • 50-150 TB/month: $0.07/GB │ │ │ │ Example: Video streaming service │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 1M users × 1 hour × 5 Mbps = 2.25 PB/month │ │ │ │ Cost: ~$150,000/month in egress alone! │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Solutions: │ │ • Compress data (gzip, brotli) │ │ • Use binary protocols (protobuf vs JSON) │ │ • CDN for static content │ │ • Pagination and streaming │ │ • Delta updates instead of full payloads │ │ │ └─────────────────────────────────────────────────────────────────┘
Fallacy 4: The Network is Secure
┌─────────────────────────────────────────────────────────────────┐ │ FALLACY 4: THE NETWORK IS SECURE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Attack vectors: │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ • Man-in-the-middle attacks │ │ │ │ • DNS spoofing │ │ │ │ • Packet sniffing │ │ │ │ • DDoS attacks │ │ │ │ • Replay attacks │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ "Internal network" is not a security boundary: │ │ • Zero trust architecture: verify everything │ │ • Assume breach has already happened │ │ │ │ Solutions: │ │ • TLS everywhere (even internal services) │ │ • mTLS for service-to-service │ │ • Network segmentation │ │ • API authentication and authorization │ │ • Encrypt data at rest and in transit │ │ • Regular security audits │ │ │ └─────────────────────────────────────────────────────────────────┘
Fallacy 5: Topology Doesn't Change
┌─────────────────────────────────────────────────────────────────┐ │ FALLACY 5: TOPOLOGY DOESN'T CHANGE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ In cloud environments, topology changes constantly: │ │ │ │ Before: After: │ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │ S1 │ │ S2 │ │ S3 │ │ S1 │ │ S4 │ │ │ │10.0 │ │10.0 │ │10.0 │ │10.0 │ │10.0 │ │ │ │.1.1 │ │.1.2 │ │.1.3 │ │.1.1 │ │.1.5 │ │ │ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ │ │ (S2, S3 terminated, │ │ S4 new instance) │ │ │ │ What causes changes: │ │ • Auto-scaling (up and down) │ │ • Deployments (rolling updates) │ │ • Failures and recovery │ │ • Network reconfigurations │ │ • Container rescheduling │ │ │ │ Solutions: │ │ • Service discovery (Consul, etcd, DNS) │ │ • Load balancers │ │ • Don't cache IP addresses │ │ • Use service meshes │ │ │ └─────────────────────────────────────────────────────────────────┘
Fallacy 6: There is One Administrator
┌─────────────────────────────────────────────────────────────────┐ │ FALLACY 6: THERE IS ONE ADMINISTRATOR │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Modern systems span multiple administrative domains: │ │ │ │ Your Application │ │ │ │ │ ├── AWS (your cloud provider) │ │ │ ├── EC2 (compute) │ │ │ ├── RDS (database) │ │ │ └── S3 (storage) │ │ │ │ │ ├── Cloudflare (CDN) │ │ │ │ │ ├── Stripe (payments) │ │ │ │ │ ├── Twilio (SMS) │ │ │ │ │ └── Customer's Network │ │ └── Their firewall, proxy, ISP... │ │ │ │ Solutions: │ │ • Design for third-party failures │ │ • Have fallbacks for external dependencies │ │ • Monitor external service health │ │ • Clear SLAs with providers │ │ • Multi-provider strategies for critical services │ │ │ └─────────────────────────────────────────────────────────────────┘
Fallacy 7: Transport Cost is Zero
┌─────────────────────────────────────────────────────────────────┐ │ FALLACY 7: TRANSPORT COST IS ZERO │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Costs of network communication: │ │ │ │ 1. Serialization/Deserialization CPU │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ JSON parsing can use 10-30% of CPU in microservices │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ 2. Memory for buffers and connections │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Each TCP connection: ~10KB kernel memory │ │ │ │ 100K connections = 1GB just for connections │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ 3. Cloud costs │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Cross-AZ: $0.01/GB │ │ │ │ Cross-region: $0.02/GB │ │ │ │ Internet egress: $0.09/GB │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ Solutions: │ │ • Use efficient serialization (protobuf) │ │ • Connection pooling │ │ • Batch requests │ │ • Consider data locality in architecture │ │ │ └─────────────────────────────────────────────────────────────────┘
Fallacy 8: The Network is Homogeneous
┌─────────────────────────────────────────────────────────────────┐ │ FALLACY 8: THE NETWORK IS HOMOGENEOUS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Your data travels through diverse infrastructure: │ │ │ │ Client ─► WiFi ─► ISP ─► Internet ─► Cloud ─► Server │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ iOS 802.11 DOCSIS Various AWS Linux │ │ Android Mesh Fiber BGP/OSPF GCP Windows │ │ Chrome 5GHz DSL Protocols Azure Containers │ │ │ │ Each hop may have: │ │ • Different MTU sizes │ │ • Different protocol support │ │ • Different reliability characteristics │ │ • Different security policies │ │ │ │ Solutions: │ │ • Use standard protocols (HTTP/2, gRPC) │ │ • Don't assume specific network features │ │ • Test on various network conditions │ │ • Handle protocol negotiation gracefully │ │ │ └─────────────────────────────────────────────────────────────────┘
Partial Failures
The defining characteristic of distributed systems: some parts can fail while others continue working.
The Challenge
┌─────────────────────────────────────────────────────────────────┐ │ PARTIAL FAILURE SCENARIOS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Scenario 1: Did my request succeed? │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Client ──── request ────► Server │ │ │ │ ◄─── timeout ──── │ │ │ │ │ │ │ │ Did the server: │ │ │ │ a) Never receive the request? │ │ │ │ b) Process it but response was lost? │ │ │ │ c) Still processing (slow)? │ │ │ │ d) Crash mid-processing? │ │ │ │ │ │ │ │ Client cannot know without additional mechanisms! │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Scenario 2: Is the server dead? │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Monitor ──── ping ────► Server │ │ │ │ ◄─── no response ──── │ │ │ │ │ │ │ │ Is the server: │ │ │ │ a) Actually dead? │ │ │ │ b) Overloaded (can't respond)? │ │ │ │ c) Network partition? │ │ │ │ d) GC pause? │ │ │ │ │ │ │ │ Monitor cannot distinguish these cases! │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘
The Two Generals Problem
┌─────────────────────────────────────────────────────────────────┐ │ TWO GENERALS PROBLEM │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Two armies need to coordinate an attack: │ │ │ │ Army A Valley Army B │ │ ┌─────────┐ (enemy territory) ┌─────────┐│ │ │ General │ ═══════════════════════════════════► │ General ││ │ │ A │ "Attack at dawn" │ B ││ │ └─────────┘ └─────────┘│ │ │ │ Problem: Messenger might be captured! │ │ │ │ General A: "Did B receive my message?" │ │ General B: "I got it! Let me send ACK..." │ │ │ │ Army A Army B │ │ ┌─────────┐ ┌─────────┐ │ │ │ ? │ ◄═════════════════════════════════ │ "ACK" │ │ │ └─────────┘ ACK might be captured! └─────────┘ │ │ │ │ General B: "Did A receive my ACK?" │ │ (Infinite regress of acknowledgments!) │ │ │ │ THEOREM: It is IMPOSSIBLE to reach agreement with │ │ unreliable communication in bounded time. │ │ │ │ Implication: Distributed consensus is fundamentally hard. │ │ Solutions: Probabilistic guarantees, timeouts, Paxos/Raft │ │ │ └─────────────────────────────────────────────────────────────────┘
Real-World System Examples
Netflix Architecture (Simplified)
┌─────────────────────────────────────────────────────────────────┐ │ NETFLIX ARCHITECTURE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Users: 230M+ │ │ Countries: 190+ │ │ Peak traffic: 15% of global internet bandwidth │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ CDN │ │ │ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │ │ │ POP │ │ POP │ │ POP │ │ POP │ │ POP │ │ POP │ │ │ │ │ │ NYC │ │ LON │ │ TYO │ │ SYD │ │ MUM │ │ SAO │ │ │ │ │ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ │ │ │ │ └───────┴───────┴───────┴───────┴───────┘ │ │ │ └─────────────────────────┬───────────────────────────────┘ │ │ │ │ │ ┌─────────────────────────┴───────────────────────────────┐ │ │ │ AWS Regions │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ │ │ US-EAST │ │ EU-WEST │ │ AP-SOUTH │ │ │ │ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ │ │ │ │ │API │ │ │ │API │ │ │ │API │ │ │ │ │ │ │ │Gateway │ │ │ │Gateway │ │ │ │Gateway │ │ │ │ │ │ │ └────┬────┘ │ │ └────┬────┘ │ │ └────┬────┘ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ┌────┴────┐ │ │ ┌────┴────┐ │ │ ┌────┴────┐ │ │ │ │ │ │ │Services │ │ │ │Services │ │ │ │Services │ │ │ │ │ │ │ │ - User │ │ │ │ - User │ │ │ │ - User │ │ │ │ │ │ │ │ - Play │ │ │ │ - Play │ │ │ │ - Play │ │ │ │ │ │ │ │ - Rec │ │ │ │ - Rec │ │ │ │ - Rec │ │ │ │ │ │ │ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │ │ │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Key patterns: │ │ • 1000+ microservices │ │ • Circuit breakers (Hystrix) │ │ • Chaos engineering (Chaos Monkey) │ │ • Edge computing for video delivery │ │ │ └─────────────────────────────────────────────────────────────────┘
UPI (Unified Payments Interface) - India
┌─────────────────────────────────────────────────────────────────┐ │ UPI ARCHITECTURE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ Scale: 10+ billion transactions/month │ │ Peak: 100,000+ TPS │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ User A's Phone NPCI User B's Bank │ │ │ │ (GPay/PhonePe) (Switch) (SBI/HDFC) │ │ │ │ ┌──────────┐ ┌─────────┐ ┌──────────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ Pay ₹100├───────►│ Route ├──────►│ Credit │ │ │ │ │ │ to B │ │ Verify │ │ User B │ │ │ │ │ │ │◄───────┤ Settle │◄──────┤ │ │ │ │ │ │ Success │ │ │ │ Done │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └──────────┘ └─────────┘ └──────────┘ │ │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ │ │ User A's Central User B's │ │ │ │ Bank (Debit) Ledger Bank (Credit) │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Distributed challenges solved: │ │ • 300+ banks as participants │ │ • Exactly-once payment semantics │ │ • Sub-second transaction completion │ │ • 99.99% availability requirement │ │ • Fraud detection in real-time │ │ │ └─────────────────────────────────────────────────────────────────┘
Interview Questions
Conceptual Questions
-
What is a distributed system? Give three reasons why we build them.
- Collection of independent computers appearing as one system
- Scalability (handle more load)
- Fault tolerance (survive failures)
- Latency (serve users from nearby locations)
-
Explain the Two Generals Problem and its implications.
- Impossible to achieve consensus with unreliable communication
- No finite number of acknowledgments can guarantee agreement
- Implies: distributed consensus requires careful algorithm design (Paxos, Raft)
-
What are the 8 fallacies of distributed computing? Pick two and explain.
- See detailed explanations above
- Key: assumptions that work locally but fail at scale
-
What is a partial failure? Why is it challenging?
- Some components fail while others work
- Cannot always distinguish between failed node vs slow node vs network partition
- Requires designing for uncertainty
System Design Questions
-
How would you design a system to handle the "network is unreliable" fallacy?
- Idempotent operations (safe to retry)
- Timeouts on all network calls
- Circuit breakers for cascading failure prevention
- Async communication with queues
- Health checks and automatic failover
-
Design a payment system that handles partial failures.
- Idempotency keys prevent duplicate charges
- Saga pattern for distributed transactions
- Reconciliation jobs for consistency
- Dead letter queues for failed operations
- Audit logs for investigation
Common Mistakes
┌─────────────────────────────────────────────────────────────────┐ │ COMMON MISTAKES │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 1. Treating remote calls like local calls │ │ ✗ userService.GetUser(id) // Looks simple, but... │ │ ✓ Add timeout, retry, circuit breaker │ │ │ │ 2. Ignoring network partitions in design │ │ ✗ "Our network is reliable" │ │ ✓ Design for partition tolerance from day 1 │ │ │ │ 3. Not considering latency in microservice decomposition │ │ ✗ 100 services = 100+ network hops │ │ ✓ Consider communication patterns before splitting │ │ │ │ 4. Assuming strong consistency everywhere │ │ ✗ "All data must be consistent immediately" │ │ ✓ Different consistency needs for different data │ │ │ │ 5. Building distributed system when you don't need one │ │ ✗ 100 users? Let's use Kubernetes + Kafka + microservices │ │ ✓ Start simple, distribute only when necessary │ │ │ └─────────────────────────────────────────────────────────────────┘
Summary
┌─────────────────────────────────────────────────────────────────┐ │ MODULE 1: KEY TAKEAWAYS │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ 1. Distributed systems: multiple computers, single system │ │ │ │ 2. We build them for: scalability, fault tolerance, latency │ │ │ │ 3. The 8 Fallacies remind us: networks fail, latency exists, │ │ bandwidth costs, topology changes, security matters │ │ │ │ 4. Partial failures are the defining challenge │ │ │ │ 5. Two Generals Problem: consensus is fundamentally hard │ │ │ │ 6. Design principles: │ │ • Expect failures │ │ • Design for uncertainty │ │ • Make operations idempotent │ │ • Use timeouts everywhere │ │ • Start simple, add complexity when needed │ │ │ └─────────────────────────────────────────────────────────────────┘
Next Module: Network Fundamentals for Distributed Systems - TCP, UDP, HTTP/2, gRPC, and how networks actually work.