Henry Nnonyelu

System Design - Event Driven Architecture and messaging – Day 42-Synchronous vs Asynchronous Communication Every API call doesn't need an immediate response.Knowing when to wait and when not to is one of the biggest differences between building small applications and designing scalable systems. What is Synchronous Communication? In synchronous communication, the caller waits until the receiver finishes processing and returns a response. Client │ ▼ Order Service │ ▼ Payment Service │ (wait) │ Response The request isn't complete until every required service responds. Examples: REST APIs gRPC Database Queries Authentication APIs What is Asynchronous Communication? In asynchronous communication, the caller doesn't wait for downstream processing to finish. Client │ ▼ Order Service │ Publish Event │ Message Queue ╱ │ ╲ ▼ ▼ ▼ Email Inventory Analytics The request returns immediately while background workers process the remaining tasks. Real-World Example Synchronous Checkout Place Order │ Charge Card │ Update Inventory │ Send Email │ Generate Invoice │ Return Success If the email service is slow... 👉 The customer waits. Asynchronous Checkout Place Order │ Charge Card │ Save Order │ Publish Event │ Return Success Background Workers • Send Email • Update Inventory • Generate Invoice • Notify Warehouse The customer receives a response immediately. Synchronous vs Asynchronous Synchronous Asynchronous Caller waits Caller continues Blocking Non-blocking Lower complexity Higher complexity Immediate response Eventual completion Tightly coupled Loosely coupled Critical workflows Background processing Use Synchronous For ✅Login ✅Payment Authorization ✅OTP Verification ✅Search ✅Profile Updates Anything requiring an immediate response. Use Asynchronous For ✅ Email ✅ Notifications ✅ Analytics ✅ Audit Logs ✅ Image Processing ✅ Report Generation ✅ Video Encoding ✅ Recommendation Engine Production Tip Don't make users wait for work they don't care about. A customer cares that: - Their payment succeeded - Their order is confirmed They don't care if the confirmation email is sent 300 ms later. That's exactly what asynchronous processing is designed for. Common Mistake Many teams make every service call synchronous. As the number of dependent services grows: - Latency increases - Failure rates increase - Availability decreases One slow dependency can delay the entire request. Key Takeaway Use synchronous communication for operations that require an immediate response. Use asynchronous communication for work that can happen in the background. The best production systems combine both.

System Design Fundamentals - Caching and Performance - Day 36 Health Checks & Failover: What Happens When a Server Goes Down? You have 3 application servers behind a load balancer. ┌──► Server A Users ──► Load Balancer ──► Server B └──► Server C Everything works perfectly. Then... Server B crashes. If the load balancer continues sending traffic to Server B: Request │ ▼ Server B │ X 500 / Timeout Users start seeing failures. So how does the load balancer know that a server should stop receiving traffic? That's where Health Checks come in. What Is a Health Check? A load balancer periodically checks whether each backend instance is healthy. Load Balancer │ ├──► Server A → Healthy ├──► Server B → Healthy └──► Server C → Healthy If a server repeatedly fails its health check: Server B │ Health Check Failed │ Marked Unhealthy │ Removed From Rotation New requests are sent only to healthy servers. Liveness vs Readiness This distinction is extremely important. Liveness Asks: "Is the application process alive?" If not, the process may need to be restarted. App Running? │ Yes → Alive No → Restart Readiness Asks: "Can this instance serve traffic right now?" An application can be alive but not ready. For example: - Database connection unavailable - Critical dependency unavailable - Application still starting - Internal initialization incomplete In that case, the instance should remain running but temporarily stop receiving traffic. Application │ Alive? → YES │ Ready? → NO │ Don't Send Traffic What Should a Health Check Verify? A simple endpoint might return: GET /health 200 OK But a useful readiness check may verify critical dependencies. For example: Application ✓ Database ✓ Redis ✓ Critical Service ✓ However, be careful. If every dependency is included blindly, one minor downstream failure could mark every application instance unhealthy and cause a larger outage. Health checks should reflect whether the instance can meaningfully serve the traffic it receives. Active vs Passive Health Checks Active Health Check The load balancer periodically sends a request. Load Balancer │ ▼ GET /health │ ▼ Server If multiple checks fail, the server is marked unhealthy. Passive Health Check The load balancer observes real traffic. If a backend repeatedly returns: Timeouts Connection Errors 5xx Responses It may temporarily remove that backend from rotation. What Is Failover? Health checks detect failure. Failover determines what happens next. Imagine: Primary Server │ X Failed │ ▼ Backup Server Traffic automatically switches to a healthy alternative. That's failover. Server Failover Suppose you have: Load Balancer │ ├──► Server A ✓ ├──► Server B X └──► Server C ✓ Server B fails. The load balancer removes it. Traffic continues through A and C. Users │ Load Balancer │ ├──► Server A └──► Server C Users may never even know that Server B went down. Database Failover Failover isn't only for application servers. Imagine: Application │ ▼ Primary DB │ Replication │ Replica DB If the primary database fails, depending on the database architecture and configuration, a replica can be promoted to become the new primary. Primary DB X │ Failover │ Replica │ New Primary This process may be automatic or manual. Multi-Zone Failover Production systems often spread infrastructure across multiple availability zones. Load Balancer │ ┌────┴────┐ │ │ Zone A Zone B │ │ Servers Servers If one zone becomes unavailable, traffic can continue through another zone. This reduces the risk of a single infrastructure failure taking down the entire application. Failure Detection Isn't Instant Imagine health checks run every: 10 seconds And the system requires: 3 consecutive failures It could take roughly 30 seconds, plus timing effects, before the server is removed. If checks are too frequent: More monitoring traffic. If thresholds are too aggressive: Temporary network issues may cause healthy servers to be removed. If thresholds are too relaxed: Users may continue hitting failed instances. Health-check configuration is a trade-off. Recovery Matters Too Suppose Server B recovers. Should traffic immediately return? Not always. A recovering server may need time to: - Warm caches - Initialize connections - Load configuration - Become fully ready A safer flow is: Server Starts │ Liveness Passes │ Readiness Passes │ Health Checks Stable │ Return to Load Balancer │ Receive Traffic Real Production Flow Users │ ▼ Load Balancer │ Health Checks │ ├──► Server A ✓ ├──► Server B X └──► Server C ✓ │ ▼ Database Primary │ Replication │ Replica Server failure? Remove unhealthy server. Database failure? Fail over to a suitable replica when the architecture supports it. Zone failure? Route traffic to healthy capacity elsewhere. Key Takeaway High availability isn't about preventing every failure. Failures will happen. The goal is to: Detect failure quickly → Stop sending traffic to unhealthy components → Fail over safely → Recover without disrupting users. Health checks tell you: "Is this instance capable of serving traffic?" Failover answers: "Where should traffic go when it isn't?" Next Day - Circuit Breaker Pattern: How to Stop One Failing Service from Taking Down Your Entire System

System design fundamentals Day - 24 Nginx Explained: The Web Server Behind Millions of Applications Yesterday we learned about Reverse Proxies. Today let's look at one of the most widely used reverse proxies in production: Nginx If you have deployed a Spring Boot, Node.js, Django, or .NET application, chances are Nginx was sitting in front of it. But why? What is Nginx? Nginx is a high-performance web server and reverse proxy. Instead of exposing your application directly to the internet... Users first connect to Nginx. Users │ ▼ Nginx │ ▼ Spring Boot App Nginx receives the request, processes it, and forwards it to the backend. Why Not Expose Spring Boot Directly? Because Nginx can handle many production concerns before the request reaches your application. It can: - Route requests - Terminate HTTPS (SSL/TLS) - Load balance traffic - Compress responses - Cache static content - Serve HTML, CSS, and JavaScript - Rate limit abusive clients This allows your application to focus on business logic. Typical Production Architecture Users │ ▼ Nginx │ ┌───────────┐ ▼ ▼ ▼ App 1 App 2 App 3 Instead of one server handling everything... Nginx distributes traffic across multiple application servers. Real Example A React + Spring Boot application might look like this: Users │ ▼ Nginx ├──────────────► React (Static Files) │ └──────────────► Spring Boot APIs One entry point. Two different workloads. Why Companies Love Nginx ✔ Extremely fast ✔ Lightweight ✔ Handles thousands of concurrent connections ✔ Easy SSL configuration ✔ Excellent reverse proxy ✔ Supports load balancing ✔ Widely used in production Simple Nginx Configuration location /api { proxy_pass http://localhost:8080; } Requests to /api are forwarded to your Spring Boot application. Key Takeaway Nginx isn't just a web server. It's the first layer of protection, routing, optimization, and scalability for modern web applications. Tomorrow we will explore API Gateway and see how it differs from Nginx.