Rafael Rivas 🇻🇪

Como Claude no nos paga (@anibal lo dice en cada episodio), hoy vamos a probar EN VIVO modelos chinos. 6 PM 🇲🇽 🇨🇷 7 PM 🇨🇴 🇵🇪 8 PM 🇻🇪 🇨🇱, 9 PM 🇦🇷 LINK ABAJO DALE RT PLISSSSS!!!

🧵 Day 21/30 — #SystemDesign Load Balancer: The silent system that keeps everything fast & alive One server handling all traffic? Works… until it doesn’t. Traffic spikes → server overload → downtime. That’s why systems use a Load Balancer. A load balancer sits between users and servers and distributes incoming requests across multiple instances. Flow: User → Load Balancer → Multiple Servers Goal: → No single server overloaded → Better performance → High availability Types (keep it simple) Layer 4 (Transport) → Works on IP + Port → Fast, less intelligent Layer 7 (Application) → Works on HTTP/HTTPS → Smart routing (headers, paths) Common Algorithms → Round Robin (equal distribution) → Least Connections (send to least busy) → IP Hash (same user → same server) → Weighted (based on server capacity) Why It Matters → Handles traffic spikes → Improves uptime → Enables horizontal scaling → Supports failover → Better latency Real Usage → AWS ELB / ALB → NGINX → HAProxy → Cloudflare Every scalable system uses one. Golden Rule Scaling = adding more servers. Load balancer = using them efficiently. #30DaysOfSystemDesign #LoadBalancing #BackendEngineering

My go-to algorithm visualizer for explaining DSA to students. algorithm-visualizer.org

🧵 Day 20/30 — #SystemDesign Kafka: The backbone behind real-time data pipelines at scale Most systems don’t just serve requests. They produce continuous streams of events — user clicks, payments, logs, metrics, notifications. Handling this data reliably and at scale is not trivial. That’s where Apache Kafka comes in. Kafka is a distributed event streaming platform used to build real-time data pipelines and streaming applications. It allows services to publish and consume events efficiently without tight coupling. ---------------------- Core Idea !! Instead of services calling each other directly: → Producer sends event to Kafka → Kafka stores it durably → Multiple consumers read and process independently Flow: Producer → Kafka Topic → Consumers One event can power many systems at once. --------------------- Key Concepts 1. Topic A category of events (e.g., orders, payments, logs) 2. Partition Topics are split into partitions for parallel processing 3. Producer Sends messages to Kafka 4. Consumer Reads messages from Kafka 5. Consumer Group Multiple consumers sharing load 6. Offset Position of message in partition These concepts define Kafka’s power. ------------------------ Why Kafka Matters → High throughput (millions of messages/sec) → Fault tolerant (replication across brokers) → Scalable horizontally → Durable storage (events persisted) → Real-time processing → Decouples systems It turns data into a streaming backbone. --------------------------- Real-World Example E-commerce order placed: → Event sent to Kafka (OrderCreated) Consumers: → Payment service processes transaction → Inventory updates stock → Notification sends email → Analytics tracks event → Recommendation system updates behavior All from one event stream. -------------------------------- Why Companies Use Kafka → Netflix for event streaming pipelines → LinkedIn (creator of Kafka) → Uber for real-time data flows → Amazon for internal streaming systems → Fintech apps for transaction streams Kafka powers modern data-driven systems. -------------------------------- Important Strength : Kafka stores events, not just forwards them. Consumers can: → Read in real-time → Replay old events → Recover from failures → Process at their own pace This makes systems resilient. ---------------------------- Challenges Most Ignore Kafka is powerful, but not simple: → Requires cluster management → Partition design is critical → Ordering only within partition → Exactly-once semantics is complex → Monitoring and tuning needed Misuse leads to complexity quickly. --------------- Kafka vs Queue Queue: → Message consumed once Kafka: → Message stored + can be consumed multiple times Kafka is more like a log system than a simple queue. Don’t use it for simple request-response systems. #30DaysOfSystemDesign #Kafka #BackendEngineering

🧵 Day 19/30 — #SystemDesign Service Discovery: How microservices find each other without hardcoding URLs In a simple app, services talk using fixed URLs: → auth-service.myapp.com
→ payment-service.myapp.com But in real systems, instances scale up/down dynamically. Containers restart. IPs change. New instances spin up during traffic spikes. So… how does one service know where another service is running right now? That’s where Service Discovery comes in. Service discovery is a mechanism that helps services dynamically find and communicate with each other without hardcoding addresses. 
 ⸻ 
 The Problem Without It : Imagine 10 instances of Payment Service. → New instances added
→ Some instances crash
→ IPs constantly change If services rely on fixed addresses: → Requests fail
→ Routing breaks
→ Manual updates needed
→ System becomes fragile This doesn’t scale. 
 ⸻ 
 How It Works : Each service instance: → Registers itself with a Service Registry
→ Shares its IP, port, health status When another service wants to call it: → It queries the registry
→ Gets a list of healthy instances
→ Sends request to one of them Flow: Service A → Registry → Service B instance Dynamic and reliable. 
 ⸻ 
 Two Main Approaches : Client-Side Discovery → Client queries registry directly
→ Client decides which instance to call Examples: → Netflix Eureka
→ Consul More control, but adds complexity to client. 
 ⸻ 
 Server-Side Discovery → Client sends request to load balancer
→ Load balancer queries registry
→ Routes request automatically Examples: → Kubernetes Services
→ AWS ELB Simpler for clients. 
 ⸻ 
 Why It Matters → Handles dynamic scaling
→ Improves fault tolerance
→ Enables auto-recovery
→ Removes hardcoded dependencies
→ Supports containerized environments
→ Essential for microservices Without it, microservices become tightly coupled again. 
 ⸻ 
 Real-World Usage → Kubernetes uses built-in service discovery via DNS
→ Netflix uses Eureka for dynamic discovery
→ AWS uses internal service routing
→ Consul used in many distributed systems Modern cloud systems rely heavily on this. 
 ⸻ 
 Health Checks (Critical) Registry doesn’t just store instances. It tracks: → Is instance alive?
→ Is it responding properly?
→ Should it receive traffic? Unhealthy instances are removed automatically. 
 ⸻ 
 Challenges Most Ignore → Registry itself becomes critical component
→ Needs high availability
→ Consistency of service list
→ Cache vs real-time updates
→ Network partitions affect discovery Service discovery must be reliable or entire system suffers. #30DaysOfSystemDesign #ServiceDiscovery #BackendEngineering