Phase 3: Architecture Patterns

Health checks, failover routing & global load balancing

Advanced ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you’re in charge of a super popular pizza restaurant that serves customers all over the world! Your main job is to make sure every single customer gets their pizza super fast, without any delays. To do this, you don't just have one chef; you have many, many chefs working in different kitchens.

To make sure everything runs smoothly, you have "kitchen managers" (these are like special computer programs). These managers constantly check on each chef. They don’t just peek in to see if a chef is there (like just seeing if a computer is turned on). Instead, they actually ask: "Can you make a fresh pepperoni pizza right now?" or "Is your oven hot enough to cook a pizza quickly?" They're making sure each chef can actually do their job and make a good pizza quickly. These quick, detailed checks are called "health checks."

Now, what if a kitchen manager finds out a chef can’t make pizzas anymore? Maybe their oven broke, or they ran out of cheese, or they're just having a tough day. The manager immediately stops sending new pizza orders to that chef. Instead, they quickly redirect all the new incoming orders to other chefs who are healthy and ready to cook. Customers never even notice a problem because their pizza order smoothly moves to another working chef. This clever redirecting is called "failover routing."

And what if you have so many customers that you have entire kitchens in different cities? If an entire kitchen in one city has a power cut and can't make any pizzas, your smart restaurant system knows about that too. It will then send all the new pizza orders from customers in that city – or even whole regions – to your kitchens in completely different towns that are still working perfectly. This powerful idea means that when people build massive online games, social media sites, or shopping apps, they use these exact tricks to make sure their service is always available to you, no matter what happens to one of their many powerful computers or even a whole building. So, when you next open your favorite app, you can know there's a whole team of "kitchen managers" working behind the scenes to keep things running smoothly, even if a "chef" or a "kitchen" needs a quick fix!

Building highly available systems hinges on accurately and rapidly detecting issues and intelligently rerouting traffic. This starts with Health Checks, which are more than just pinging a server; they're granular tests to ensure a service or application endpoint is truly operational and responsive, often involving HTTP, TCP, or even custom application-level checks. A robust health check probes not just the underlying infrastructure but the application's ability to serve requests successfully. These checks are the 'eyes and ears' of your HA setup, providing the critical signals that determine if a component is fit to receive traffic or needs to be isolated.

Once a health check identifies a failing component, Failover Routing immediately kicks in. This mechanism, typically managed by a load balancer or a DNS service, re-directs client requests away from unhealthy instances or entire clusters to their healthy counterparts. Within a single region or availability zone, a local load balancer continuously monitors its backend targets via health checks and automatically removes unhealthy ones from its rotation, directing all new traffic to the healthy subset. For more severe outages, like an entire Availability Zone failing, routing can be reconfigured at the DNS level or by a regional load balancer to send traffic to a different, healthy AZ.

Extending this concept globally introduces Global Load Balancing (GLB), often implemented via services like AWS Route 53 with failover/latency routing, Google Cloud's Global External HTTP(S) Load Balancer, or Azure Front Door. GLB doesn't just manage traffic within a region; it orchestrates traffic distribution across multiple, geographically dispersed regions or data centers. By performing health checks against entire regions or primary endpoints within them, GLB can intelligently route users to the closest, lowest-latency, or most available region. If an entire region experiences an outage, GLB can perform a complete regional failover, directing all traffic to a pre-defined disaster recovery region, ensuring maximum resilience and a seamless user experience even during widespread disruptions.

Key Takeaways

  • Health checks are critical for proactive failure detection at granular levels (instance, service, region).
  • Failover routing automatically directs traffic away from unhealthy components based on health check signals.
  • Global Load Balancing extends HA across geographies, enabling multi-region disaster recovery and performance optimization.
  • These three elements form a cohesive system to maintain service continuity and resilience across various failure domains.

Code Example

yaml
HealthCheck:
  Enabled: true
  IntervalSeconds: 30
  Path: /healthz # Application-specific endpoint to check service health
  Port: traffic-port # Check the same port the application uses
  Protocol: HTTP
  TimeoutSeconds: 5
  HealthyThresholdCount: 3 # Number of consecutive successes for an instance to be considered healthy
  UnhealthyThresholdCount: 3 # Number of consecutive failures for an instance to be considered unhealthy
  Matcher:
    HttpCode: "200" # Expect HTTP 200 OK for a healthy response

How this code works

This HealthCheck configuration is a vital component for ensuring High Availability and robust global load balancing. Its primary job is to constantly monitor the health of individual application instances. By doing so, it automatically determines which instances are ready to receive user traffic and which should be temporarily taken out of rotation, enabling seamless failover routing when issues arise. This ensures that users always connect to a functioning part of the system, even if some backend instances encounter problems.

The configuration works by periodically sending requests to the application. Enabled: true activates the checks, with IntervalSeconds defining how often a check occurs and TimeoutSeconds setting the maximum wait time for a response. The Path: /healthz and Port: traffic-port specify the exact location and network port on the application where the health check endpoint listens, using Protocol: HTTP. A subtle but important detail is the Matcher.HttpCode: "200". This doesn't just check if the application is reachable; it specifically verifies that the application responds correctly with an HTTP 200 OK status. An instance might be running but failing internally, and only a "200" indicates true health. Finally, HealthyThresholdCount and UnhealthyThresholdCount prevent false alarms by requiring multiple consecutive successes or failures before an instance's status changes.

Related Articles

Hand-picked reads to go deeper on high availability.

Back to Cloud Architect Roadmap