| DNS resolution order | Browser cache → OS cache → recursive resolver → root → TLD → authoritative server |
| TTL | Controls cache lifetime of a record; low TTL = faster failover, higher query load |
| L4 load balancer | Routes on IP/port (TCP/UDP) — fast, protocol-agnostic, no payload inspection |
| L7 load balancer | Routes on HTTP data — host, path, headers, cookies — enables content-based rules |
| Round robin | Simplest algorithm; cycles through servers evenly, ignores current load |
| Consistent hashing | Only ~1/n keys remap when a node is added/removed, versus almost all keys with modulo hashing |
| CDN edge cache | Serves cached content from PoPs near users, cutting latency and origin load |
| Health check | Active/passive probes that pull unhealthy backends out of rotation automatically |
health checks + routing algorithm
DNS, Load Balancer & CDN Interview Questions & Answers
Q1. What is DNS and why does the internet need it?
A: DNS (Domain Name System) is a globally distributed, hierarchical directory that translates human-readable domain names like example.com into machine-usable IP addresses. Computers route packets using IP addresses, not names, so without DNS every user would need to memorize numeric addresses for every service they visit. DNS also decouples a domain from a specific server, letting operators change backend infrastructure without changing the name users type.
Q2. Walk through the full DNS resolution process step by step for a first-time lookup.
A: The browser first checks its own cache, then the OS resolver cache; if neither has the answer, the query goes to a configured recursive resolver (e.g., an ISP resolver or 1.1.1.1). The recursive resolver queries a root nameserver, which returns a referral to the TLD nameserver for ".com"; the TLD server refers it to the domain's authoritative nameserver. The authoritative server returns the actual A/AAAA record, which the recursive resolver caches and returns to the client, and the browser can finally open a TCP connection to that IP.
Q3. What is the difference between a recursive resolver and an iterative query?
A: A recursive query means the client asks the resolver for a final answer and expects the resolver to do all the follow-up work itself, including chasing referrals. An iterative query is what the recursive resolver does to the upstream servers — each server returns either the answer or a referral to the next server closer to the answer, and the resolver follows that chain. In practice, clients issue recursive queries to their resolver, while the resolver issues iterative queries to root, TLD, and authoritative servers.
Q4. What is a stub resolver?
A: A stub resolver is the lightweight DNS client built into an operating system or application that cannot walk the full hierarchy itself. It simply forwards lookup requests to a configured recursive resolver and returns whatever answer comes back, relying entirely on that resolver to do root/TLD/authoritative traversal and caching. Most consumer devices and containers only ever run a stub resolver.
Q5. What role do root nameservers play in DNS resolution?
A: Root nameservers sit at the top of the DNS hierarchy and don't know specific domain records; they only know which TLD nameservers are authoritative for each top-level domain (.com, .org, .io, etc.). There are 13 logical root server identities (a-root through m-root), each served by many physically distributed, anycast-replicated machines worldwide for resilience. Every uncached recursive resolution begins by asking a root server for a referral.
Q6. What is a TLD nameserver?
A: A TLD (top-level domain) nameserver is authoritative for an entire domain suffix such as .com, .net, or .io, and it maintains referrals to the authoritative nameservers of every registered domain under that suffix. When a root server refers a resolver to the .com TLD servers, those servers respond with the NS records pointing to example.com's actual authoritative nameservers, not the final IP address itself.
Q7. What is an authoritative nameserver?
A: An authoritative nameserver is the source of truth for a specific domain's DNS records — it's where the actual A, MX, TXT, and other records live, typically managed via a registrar or DNS provider like Route 53 or Cloudflare. Unlike recursive resolvers, authoritative servers don't cache or chase other servers; they simply answer queries about the zones they host directly from their own configured data.
Q8. What transport protocol does DNS use, and why?
A: DNS primarily uses UDP on port 53 because most queries and responses are small and UDP avoids the connection-setup overhead of TCP, making lookups fast. UDP's lack of guaranteed delivery is acceptable since a lost query is simply retried by the resolver with minimal cost. DNS also supports TCP on port 53 for cases where a single UDP datagram isn't sufficient.
Q9. When does DNS fall back to TCP instead of UDP?
A: DNS switches to TCP when a response would exceed the practical UDP datagram size (traditionally 512 bytes without EDNS0, or larger with EDNS0 but still capped) — for example, responses with DNSSEC signatures, large TXT records, or many records in one answer. Zone transfers (AXFR/IXFR) between primary and secondary nameservers also always use TCP, since they can carry an entire zone's worth of data reliably.
Q10. What is DNS over HTTPS (DoH) and DNS over TLS (DoT), and why were they introduced?
A: DoT wraps DNS queries in a TLS-encrypted TCP connection (typically port 853), while DoH sends DNS queries as HTTPS requests, usually on port 443. Both were introduced to fix the fact that plain DNS over UDP/TCP is unencrypted, letting ISPs and network intermediaries see (and sometimes tamper with or censor) which domains a user is resolving. DoH has the added benefit of blending in with regular HTTPS traffic, making it harder to selectively block.
Q11. What is a fully qualified domain name (FQDN)?
A: An FQDN specifies the exact, unambiguous location of a host in the DNS hierarchy, including all labels up to the root, such as www.example.com. — the trailing dot denotes the implicit root zone. Unlike a relative or partial hostname, an FQDN leaves no ambiguity for the resolver about which zone to search, so it can go straight to querying without appending a local search domain suffix.
Q12. In what order does a browser check caches before issuing a network DNS query?
A: The browser first checks its own internal DNS cache (many browsers cache for a short, fixed duration regardless of TTL), then the operating system's resolver cache (e.g., managed by systemd-resolved or the Windows DNS client service). Only if both are misses does an actual query go out over the network to the configured recursive resolver. This layered caching is why DNS changes can appear to "stick" locally even after the authoritative record has changed.
Q13. What is negative caching in DNS (NXDOMAIN caching)?
A: Negative caching means resolvers also cache the fact that a domain or record does not exist (an NXDOMAIN or NODATA response), not just successful answers. The cache duration for negative responses is controlled by the SOA record's minimum/negative-TTL field, not the record's own TTL, since there is no record. This prevents resolvers from repeatedly querying authoritative servers for names that consistently don't resolve.
Q14. What is domain delegation and how do NS records implement it?
A: Delegation is how a parent zone hands off authority for a subdomain to a different set of nameservers. The parent zone (e.g., the .com TLD zone) publishes NS records for example.com pointing to example.com's own nameservers, effectively saying "I don't know the details, ask these servers instead." This is what allows a company to run its own DNS infrastructure while still being reachable under a TLD it doesn't own.
Q15. Why do companies run public recursive resolvers like Google's 8.8.8.8 or Cloudflare's 1.1.1.1?
A: Public resolvers offer faster, more reliable, and often more private resolution than many default ISP resolvers, which can be slow, log queries for advertising, or inject non-standard results (like search redirects) on NXDOMAIN. They also typically support DNSSEC validation and encrypted transports like DoH/DoT. For the operators, running a resolver provides valuable aggregate traffic insight and reinforces their broader infrastructure ecosystem.
Q16. What is an A record?
A: An A (Address) record maps a hostname directly to an IPv4 address, and it's the most fundamental record type used to make a domain reachable. A zone can have multiple A records for the same name, in which case resolvers typically return them all and clients (or a simple DNS-based load-balancing scheme) may round-robin between them.
www.example.com. 3600 IN A 203.0.113.10Q17. What is an AAAA record and how does it differ from an A record?
A: An AAAA record maps a hostname to a 128-bit IPv6 address, functionally the IPv6 equivalent of an A record's IPv4 mapping. Dual-stack hosts typically publish both an A and an AAAA record for the same name, and modern clients use "Happy Eyeballs" logic to race IPv6 and IPv4 connections and use whichever succeeds first with the lowest latency.
Q18. What is a CNAME record, and what are its restrictions?
A: A CNAME (Canonical Name) record makes one hostname an alias for another, telling the resolver "the real name for this is X, go look that up instead." A CNAME cannot coexist with any other record type at the same name (no A record alongside a CNAME for the same label), because a CNAME redirects the entire query, not just part of it, which would create ambiguity.
blog.example.com. 3600 IN CNAME ghs.googlehosted.com.Q19. Why can't you place a CNAME record at the zone apex (root domain)?
A: The zone apex (e.g., example.com itself, not a subdomain) must hold an SOA record and typically NS records, and DNS rules forbid a CNAME from coexisting with any other record type at the same name. Since the apex always needs those infrastructural records, you can't alias it away with a CNAME. Providers work around this with proprietary "ALIAS," "ANAME," or "flattened CNAME" records that behave like a CNAME but are resolved server-side into an A/AAAA record at the apex.
Q20. What is an MX record and how does priority work?
A: An MX (Mail Exchange) record specifies which mail servers accept email for a domain and in what preference order, using a numeric priority value where lower numbers are tried first. Sending mail servers attempt the lowest-priority (most preferred) MX host first, falling back to higher-priority values if it's unreachable, which naturally provides mail delivery redundancy.
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.Q21. What is a TXT record and what are its common real-world uses?
A: A TXT record stores arbitrary free-text data attached to a hostname, originally intended for human-readable notes but now widely repurposed for machine-verifiable metadata. Common uses include SPF (authorized mail senders), DKIM public keys (email signing), DMARC policy, and domain-ownership verification tokens for services like Google Search Console or ACME certificate issuance.
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"Q22. What is an NS record?
A: An NS (Nameserver) record identifies which servers are authoritative for a zone, both at the parent-zone level (to implement delegation) and inside the zone itself (to declare the zone's own authoritative servers). A domain should have multiple NS records pointing to geographically and topologically diverse servers so DNS resolution survives the loss of any single nameserver.
Q23. What is an SOA record and what fields does it contain?
A: The SOA (Start of Authority) record marks the beginning of a zone and holds administrative metadata: the primary nameserver, an admin contact email, a serial number (incremented on every change, used by secondaries to detect updates), and timers — refresh, retry, expire, and minimum/negative-cache TTL. Secondary nameservers use the serial number to decide whether a zone transfer is needed.
Q24. What is a PTR record (reverse DNS) used for?
A: A PTR record maps an IP address back to a hostname — the inverse of an A record — and lives in a special reverse zone under in-addr.arpa (IPv4) or ip6.arpa (IPv6). Reverse DNS is commonly checked by mail servers as a spam-reputation signal (mail from an IP with no matching PTR is often flagged) and is useful for identifying hosts in network logs.
10.113.0.203.in-addr.arpa. 3600 IN PTR www.example.com.Q25. What is a CAA record?
A: A CAA (Certification Authority Authorization) record restricts which certificate authorities are permitted to issue TLS certificates for a domain. If a domain publishes a CAA record naming only "letsencrypt.org," a compliant CA that receives a request to issue a certificate for that domain from a different, unauthorized CA must refuse, reducing the risk of mis-issued certificates.
Q26. What is an SRV record?
A: An SRV (Service) record advertises the hostname and port for a specific service (like SIP, XMPP, or a Kubernetes headless service), along with priority and weight fields similar to MX records for failover and load distribution. Unlike an A record, SRV lets a single domain point clients to different hosts and ports per service, rather than assuming a fixed well-known port.
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.Q27. What is the difference between CNAME and ALIAS/ANAME records?
A: A CNAME is a standard DNS record that fully aliases a name at the protocol level, and it cannot be used at the zone apex. ALIAS/ANAME are non-standard, provider-specific record types (offered by Route 53 as "Alias," by some DNS hosts as "ANAME") that look up the target's IP addresses server-side and return them as if they were A/AAAA records, allowing apex-level aliasing where a real CNAME would be illegal.
Q28. What is a wildcard DNS record and when is it used?
A: A wildcard record, written with a leading asterisk like *.example.com, matches any subdomain that doesn't have its own explicit record, returning the same answer for all of them. It's commonly used for multi-tenant SaaS platforms where each customer gets a subdomain (tenant1.example.com, tenant2.example.com) routed to the same infrastructure without provisioning a DNS entry per tenant.
Q29. Show an example of a small DNS zone file combining multiple record types.
A: A zone file lists every record for a domain, starting with the mandatory SOA and NS records, followed by whatever A, CNAME, MX, and TXT records the domain needs. Each line follows the pattern name / TTL / class (IN) / type / data, and a trailing dot marks a fully qualified name.
$TTL 3600
example.com. IN SOA ns1.example.com. admin.example.com. (2026080801 7200 3600 1209600 3600)
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
example.com. IN A 203.0.113.10
www IN CNAME example.com.
example.com. IN MX 10 mail1.example.com.
example.com. IN TXT "v=spf1 -all"Q30. What is a DNS zone transfer (AXFR/IXFR)?
A: A zone transfer replicates an entire zone's records from a primary (master) nameserver to secondary nameservers, keeping them in sync. AXFR performs a full transfer of every record, while IXFR transfers only the incremental changes since a secondary's last known SOA serial number, which is far more efficient for large zones with frequent small updates. Zone transfers should be restricted to trusted secondary IPs to prevent zone enumeration by outsiders.
Q31. What is split-horizon (split-brain) DNS?
A: Split-horizon DNS serves different answers for the same domain name depending on where the query originates — internal corporate network clients might resolve internal-app.example.com to a private IP, while external clients get an NXDOMAIN or a public-facing IP. It's commonly used so internal services stay reachable by name from within a VPN/private network without exposing internal topology to the public internet.
Q32. What is TTL in DNS and what does it control?
A: TTL (Time To Live) is a value, in seconds, published alongside every DNS record that tells caching resolvers how long they may reuse the answer before re-querying the authoritative server. It directly controls the trade-off between freshness and load: a long TTL reduces query volume on authoritative servers and speeds up repeat lookups, while a short TTL lets changes (like an IP failover) propagate to clients faster.
Q33. How do you choose a TTL value — what's the trade-off?
A: Stable, rarely changing records (like MX or NS) typically use long TTLs (hours to a day) since fast propagation isn't needed and it minimizes load and latency. Records tied to infrastructure that might need to fail over quickly (like an A record pointing at a load balancer) often use short TTLs (60-300 seconds), accepting higher query volume in exchange for the ability to redirect traffic within minutes if something breaks.
Q34. Where along the resolution chain does DNS caching happen?
A: Caching happens at multiple independent layers: the browser's internal cache, the OS-level stub resolver cache, the ISP's or configured recursive resolver's cache, and sometimes intermediate forwarding resolvers inside a corporate network. Each layer honors the record's TTL independently, which is why a change can appear at different times to different users depending on what's already cached at each hop.
Q35. Why can DNS changes take time to "propagate" globally?
A: "Propagation" is really just a description of caches at different layers gradually expiring and being refreshed with the new value — there's no active push mechanism that broadcasts a change everywhere at once. The perceived delay is bounded by the old record's TTL: a resolver that cached the old answer with a 24-hour TTL won't re-query until that TTL elapses, no matter how quickly the authoritative record was updated.
Q36. What technique do teams use to make a future DNS cutover fast (TTL priming)?
A: Before a planned migration or failover event, teams lower the TTL on the relevant record well in advance (e.g., from 3600 to 60 seconds), wait for the old, longer TTL to fully expire from caches worldwide, and only then perform the cutover. This ensures that when the record is actually changed, resolvers pick up the new value within roughly the new short TTL instead of being stuck with a stale cached answer for hours.
Q37. What is DNS cache poisoning and how does DNSSEC mitigate it?
A: DNS cache poisoning is an attack where a malicious actor injects a forged DNS response into a resolver's cache, tricking it into returning an attacker-controlled IP for a legitimate domain — often by guessing the transaction ID and source port of an in-flight query. DNSSEC mitigates this by cryptographically signing DNS records with a chain of trust rooted at the DNS root zone, so a resolver can verify a response's authenticity and reject forged or tampered data.
Q38. What is DNSSEC and how does it work at a high level?
A: DNSSEC adds digital signatures to DNS records using public-key cryptography, letting resolvers verify that a response genuinely came from the zone's authoritative server and wasn't altered in transit. Each zone signs its records with a private key and publishes the corresponding public key (via DNSKEY records); trust is chained upward through DS records in the parent zone, all the way to a trust anchor at the root, so a validating resolver can verify the whole chain without pre-trusting every zone individually.
Q39. What is a DNS amplification (reflection) attack?
A: In a DNS amplification attack, the attacker sends a small DNS query to an open recursive resolver with the source IP address spoofed to the victim's address, requesting a record type (like ANY or TXT) that produces a much larger response. The resolver sends that large response to the victim rather than the attacker, and because the response is many times larger than the query, a small amount of attacker bandwidth generates a disproportionately large flood at the victim — mitigated by disabling open resolvers and enforcing response-rate limiting.
Q40. How do you inspect and debug DNS resolution from the command line?
A: The dig tool (or nslookup on Windows) queries DNS directly and shows the full response including TTL, record type, and which server answered. Using +trace replays the entire resolution path from the root nameservers down to the authoritative server, which is invaluable for diagnosing delegation misconfigurations or unexpected cached answers.
$ dig www.example.com A +short
203.0.113.10
$ dig www.example.com A +trace
; follows the full chain: root -> .com TLD -> example.com authoritative
$ dig @8.8.8.8 example.com MX
; queries a specific resolver directly, bypassing local cacheQ41. What is anycast DNS and how does it improve availability and latency?
A: Anycast lets the same IP address be announced via BGP from many physically distributed servers around the world; network routing automatically directs each client to the topologically nearest announcing server. For DNS, this means a query to a resolver's anycast IP (like 1.1.1.1) is answered by whichever nearby datacenter is healthy and closest, giving both lower latency and automatic failover if one location goes down, all without changing the client-facing IP address.
Q42. What is a load balancer and why do distributed systems need one?
A: A load balancer sits in front of a pool of backend servers and distributes incoming requests across them according to a chosen algorithm, so no single server is overwhelmed while others sit idle. It also enables horizontal scaling (add more backends transparently), high availability (route around failed instances), and zero-downtime deployments (drain and replace instances one at a time) — none of which are possible if clients talk directly to a single fixed server.
Q43. What is the difference between Layer 4 and Layer 7 load balancing?
A: A Layer 4 (transport-layer) load balancer routes based only on IP address and TCP/UDP port information, without looking at the payload, making its decision purely on connection-level data. A Layer 7 (application-layer) load balancer terminates and inspects the actual HTTP request — host header, URL path, cookies, custom headers — and can route different requests to different backend pools based on that content.
Q44. What is the performance/flexibility trade-off between L4 and L7 load balancers?
A: L4 balancers are faster and use less CPU because they never parse the request payload — they just forward packets based on connection tuples — but they can't make content-aware routing decisions or terminate TLS meaningfully. L7 balancers add latency and compute overhead from parsing HTTP and often terminating TLS, but in exchange gain the ability to do path-based routing, header manipulation, request retries, and application-aware health checks.
Q45. What is a hardware load balancer versus a software load balancer?
A: A hardware load balancer (like an F5 BIG-IP appliance) is dedicated physical equipment with specialized network processors optimized for extremely high throughput and low latency, typically deployed in traditional datacenters. A software load balancer (nginx, HAProxy, Envoy, or cloud-managed services like AWS ELB) runs on commodity servers or as a managed cloud service, trading some raw performance for flexibility, lower cost, and easier automation/scaling in cloud-native environments.
Q46. Give real-world examples of L4 vs L7 load balancers.
A: Common L4 examples include AWS Network Load Balancer (NLB), Linux's IPVS/LVS, and HAProxy in TCP mode. Common L7 examples include AWS Application Load Balancer (ALB), nginx and HAProxy in HTTP mode, Envoy, and Google Cloud's HTTP(S) Load Balancer — all of which can inspect and route on HTTP-level details.
Q47. What is SSL/TLS termination at a load balancer?
A: TLS termination means the load balancer decrypts incoming HTTPS traffic itself, holding the private key and certificate, and then forwards the request to backends as plain HTTP over the internal network. This centralizes certificate management in one place, offloads the CPU cost of encryption from application servers, and lets the load balancer inspect the decrypted request for L7 routing decisions.
Q48. What is SSL passthrough and when would you use it instead of termination?
A: SSL passthrough forwards the encrypted TLS stream unmodified all the way to the backend server, which performs its own decryption, meaning the load balancer operates purely at L4 for that traffic and never sees plaintext. It's used when backends must handle their own certificates for compliance/mutual-TLS reasons, or when end-to-end encryption is required so that no intermediate hop, including the load balancer, ever has access to unencrypted data.
Q49. What is a listener in a load balancer's configuration model?
A: A listener defines the protocol and port on which the load balancer accepts incoming client connections (for example, HTTPS on 443), along with rules for what to do with matching traffic — which target group to forward to, what TLS certificate to present, and any header/redirect rules. A single load balancer commonly runs multiple listeners, such as one for HTTP:80 that redirects to HTTPS:443, and another for the actual HTTPS traffic.
Q50. What is a target group / backend pool?
A: A target group (AWS terminology) or backend pool (HAProxy/nginx terminology) is the named set of backend servers or instances that a listener's rules forward matching traffic to, along with the health check configuration and load-balancing settings specific to that group. Using multiple target groups lets one load balancer route, say, /api/* to one pool of servers and /static/* to a different pool.
Q51. What is connection draining (deregistration delay)?
A: Connection draining is a grace period during which a backend being removed from rotation (due to a deploy, scale-down, or health check failure) stops receiving new requests but is allowed to finish serving requests already in flight before being fully terminated. Without it, in-flight requests would be abruptly cut off mid-response whenever an instance is taken out of service, causing avoidable client-facing errors.
Q52. What is Layer 7 content-based routing (path-based, host-based)?
A: Content-based routing lets an L7 load balancer send different requests to different backend pools based on the actual HTTP request content — for example, routing requests with Host: api.example.com to an API service and Host: www.example.com to a web frontend (host-based), or routing /images/* to a static-asset service and /checkout/* to an order service (path-based). This lets many logically distinct services share a single public entry point and certificate.
Q53. Show an example nginx upstream + reverse proxy configuration.
A: The upstream block declares a named backend pool with optional per-server weights and a backup server, and a server block's proxy_pass directive forwards matching requests to that pool. nginx handles TLS termination, connection reuse to backends, and basic weighted round-robin distribution out of the box.
upstream backend_pool {
server 10.0.1.10:8080 weight=3;
server 10.0.1.11:8080 weight=1;
server 10.0.1.12:8080 backup;
}
server {
listen 80;
location / {
proxy_pass http://backend_pool;
proxy_set_header Host $host;
}
}Q54. Show an example HAProxy configuration for round-robin load balancing.
A: HAProxy separates concerns into a frontend (where clients connect) and a backend (the pool of real servers plus the balancing algorithm and health check settings). The balance roundrobin directive selects the algorithm, and check on each server line enables active health checking.
frontend http_front
bind *:80
default_backend http_back
backend http_back
balance roundrobin
server app1 10.0.1.10:8080 check
server app2 10.0.1.11:8080 check
server app3 10.0.1.12:8080 checkQ55. What is a Network Load Balancer best suited for?
A: A Network Load Balancer (L4) is best suited for extreme-performance, low-latency scenarios that need to preserve the raw client IP and handle millions of requests per second — TCP/UDP-based protocols, gaming servers, IoT ingestion, and situations where the application itself needs to terminate TLS or handle a non-HTTP protocol. It's the right choice when content-based routing isn't needed and raw throughput/latency matters most.
Q56. What is an Application Load Balancer best suited for?
A: An Application Load Balancer (L7) is best suited for HTTP/HTTPS web applications and microservices that benefit from content-based routing, such as routing by path to different microservices, host-based routing for multi-tenant domains, WebSocket support, and native integration with authentication or WAF rules. It trades some raw throughput for this application-awareness.
Q57. What is a Gateway Load Balancer and what problem does it solve?
A: A Gateway Load Balancer operates at L3/L4 and is designed to transparently insert third-party network appliances — firewalls, intrusion detection, deep packet inspection — into the traffic path without the appliance needing to be topology-aware. It combines a transparent gateway with load balancing across a fleet of appliance instances, so traffic can be scaled through security/inspection tooling the same way application traffic is scaled across app servers.
Q58. What is the difference between a load balancer and an API gateway?
A: A load balancer's core job is distributing traffic across healthy backend instances of typically one logical service. An API gateway is a higher-level component that sits in front of many distinct backend services and additionally handles concerns like authentication/authorization, rate limiting, request/response transformation, API versioning, and aggregating multiple backend calls into one client-facing response — it often uses a load balancer internally but does much more than balance load.
Q59. What is round-robin load balancing?
A: Round robin cycles through the list of backend servers in a fixed order, sending each new request to the next server in the sequence and wrapping back to the start after reaching the end. It's simple and guarantees an even distribution of request count, but it ignores real-time server load, so if backends have unequal capacity or requests have unequal cost, round robin can leave some servers overloaded while others are underutilized.
class RoundRobinBalancer {
private final List<String> servers;
private int index = 0;
RoundRobinBalancer(List<String> servers) {
this.servers = servers;
}
synchronized String next() {
String server = servers.get(index);
index = (index + 1) % servers.size();
return server;
}
}Q60. What is weighted round-robin and when is it useful?
A: Weighted round robin assigns each server a weight proportional to its capacity, so a server with weight 3 receives roughly three times as many requests as one with weight 1 over the same cycle, instead of the strictly equal distribution of plain round robin. It's useful in heterogeneous fleets — for example, during a gradual instance-type migration, or when some nodes have more CPU/memory and can genuinely handle more concurrent load than others.
Q61. What is the least-connections algorithm?
A: Least connections routes each new request to whichever backend currently has the fewest active (in-flight) connections, rather than blindly cycling through servers. This adapts better than round robin when requests have highly variable processing times, since a server stuck processing several slow requests will naturally receive fewer new ones until it catches up.
class LeastConnectionsBalancer {
private final Map<String, AtomicInteger> activeConnections = new ConcurrentHashMap<>();
String pick() {
return activeConnections.entrySet().stream()
.min(Comparator.comparingInt(e -> e.getValue().get()))
.map(Map.Entry::getKey)
.orElseThrow();
}
void onRequestStart(String server) {
activeConnections.computeIfAbsent(server, s -> new AtomicInteger()).incrementAndGet();
}
void onRequestEnd(String server) {
activeConnections.get(server).decrementAndGet();
}
}Q62. What is weighted least-connections?
A: Weighted least connections divides each server's active connection count by its assigned weight before comparing, so a higher-capacity server can carry proportionally more concurrent connections before it's considered "as busy" as a lower-capacity one. It combines the adaptiveness of least-connections with the capacity-awareness of weighting, which is why it's a common default in production L7 load balancers for heterogeneous fleets.
Q63. What is IP hash-based load balancing?
A: IP hash computes a hash of the client's source IP address and uses it to deterministically pick which backend server handles that client's requests, so the same client consistently lands on the same server as long as the pool doesn't change. It's a simple way to achieve session affinity without cookies, though it can distribute load unevenly if many clients sit behind the same NAT/proxy IP, and any change in pool size remaps most clients.
Q64. What is consistent hashing and why is it used for load balancing?
A: Consistent hashing places both servers and request keys onto a conceptual hash ring (a circular hash space); a key is routed to the first server encountered walking clockwise from the key's hash position. It's used because, unlike naive modulo hashing (hash(key) % serverCount), adding or removing one server only remaps the keys between that server and its neighbor on the ring — not almost every key in the system.
class ConsistentHashRing {
private final SortedMap<Long, String> ring = new TreeMap<>();
void addServer(String server) {
ring.put(hash(server), server);
}
String getServer(String key) {
if (ring.isEmpty()) throw new IllegalStateException("No servers");
long h = hash(key);
SortedMap<Long, String> tail = ring.tailMap(h);
Long nodeHash = tail.isEmpty() ? ring.firstKey() : tail.firstKey();
return ring.get(nodeHash);
}
private long hash(String s) {
return s.hashCode() & 0xFFFFFFFFL; // simplified; use MurmurHash in production
}
}Q65. How does consistent hashing minimize remapping when nodes are added or removed?
A: Because keys only "belong" to the nearest server clockwise on the ring, removing a server only affects the keys that were mapped to it — they simply move to the next server clockwise, while every other key's mapping is untouched. Adding a new server only steals keys from the single existing server whose ring segment it's inserted into. On average, only about 1/n of the keys move when the cluster size changes by one node, versus nearly all keys with modulo hashing.
Q66. What is the "hot spot" problem in naive consistent hashing, and how do virtual nodes fix it?
A: With only one ring position per physical server, random hash placement can leave some servers responsible for a much larger arc of the ring than others, causing uneven load ("hot spots") even though the algorithm is theoretically balanced. Virtual nodes fix this by hashing each physical server to many points on the ring (typically 100-200), so each server's total ring coverage is the sum of many small, randomly scattered arcs, averaging out to a much more even distribution.
void addServerWithVirtualNodes(String server, int virtualNodeCount) {
for (int v = 0; v < virtualNodeCount; v++) {
ring.put(hash(server + "#" + v), server);
}
}
// 100-200 virtual nodes per physical server smooths the distributionQ67. What is the "power of two random choices" algorithm and why does it outperform pure random selection?
A: Instead of picking one server uniformly at random (which can send multiple requests to an already-busy server by chance) or checking every server's load (which doesn't scale), power-of-two-choices picks two servers at random and routes to whichever of those two currently has less load. This simple tweak provably produces a far more balanced distribution than pure random choice, with only O(1) overhead per request, which is why it's used in systems like Envoy's load balancer.
class PowerOfTwoChoices {
private final List<String> servers;
private final Map<String, AtomicInteger> load;
private final Random rnd = new Random();
String pick() {
String a = servers.get(rnd.nextInt(servers.size()));
String b = servers.get(rnd.nextInt(servers.size()));
return load.get(a).get() <= load.get(b).get() ? a : b;
}
}Q68. What is the least-response-time algorithm?
A: Least response time routes each request to the server with the lowest combination of active connection count and observed average response latency, blending the adaptiveness of least-connections with a real measure of how fast each backend is actually responding. It handles cases where a server has few connections but is nonetheless slow (e.g., due to a noisy-neighbor CPU issue), which pure least-connections would miss.
Q69. What is URL/hash-based routing used for (e.g., CDN cache-key routing)?
A: URL hash-based routing hashes the request path (or another cache key) to consistently direct requests for the same resource to the same backend or cache node, maximizing cache hit rates by ensuring a given object is always fetched from or cached on the same place instead of being scattered across the whole pool. It's widely used in CDN and reverse-proxy caching tiers where cache locality matters more than perfectly even request distribution.
Q70. How do you decide which algorithm to use for a stateful versus a stateless service?
A: For stateless services, where any backend can handle any request equally well, load-aware algorithms like least-connections or power-of-two-choices maximize efficiency since there's no reason to pin a client to one server. For stateful services that keep in-memory session or connection state on a specific server, IP hash or cookie-based sticky sessions are needed so a client's subsequent requests land back on the server holding its state — though the better long-term fix is usually externalizing that state so any backend can serve any request.
Q71. What is the difference between static and dynamic load balancing algorithms?
A: Static algorithms (round robin, weighted round robin, IP hash) make routing decisions based on fixed, pre-configured rules that don't consider current server state — the outcome for a given input is always the same regardless of live load. Dynamic algorithms (least connections, least response time, power-of-two-choices) continuously incorporate real-time signals like active connections or latency, adapting their decisions as backend conditions change.
Q72. How is traffic shifted gradually for a canary deployment at the load balancer level?
A: A small percentage of traffic is routed to the new ("canary") version by assigning it a small weight relative to the stable version in a weighted routing configuration, then gradually increasing the canary's weight (and monitoring error rates/latency at each step) until it reaches 100% or is rolled back. This limits the blast radius of a bad deploy to only the fraction of users hitting the canary weight at any point.
upstream backend_pool {
server 10.0.1.10:8080 weight=95; # stable version
server 10.0.1.20:8080 weight=5; # canary version
}Q73. What is Envoy's "least request" load balancing policy?
A: Envoy's least-request policy is a variant of power-of-two-choices: it randomly samples a small number of candidate hosts (default two) and picks the one with fewer active requests, weighting the selection by each host's configured weight if unequal. It's designed to approximate true least-connections behavior at scale without the coordination overhead of tracking global state across every proxy instance.
Q74. What is a health check in the context of load balancing?
A: A health check is a periodic probe the load balancer sends to each backend to determine whether it's capable of serving traffic — commonly a TCP connect attempt, an HTTP GET to a dedicated endpoint like /healthz, or a custom protocol check. Backends that fail enough consecutive checks are automatically removed from rotation, and re-added once they pass enough consecutive checks again, without requiring any manual intervention.
Q75. What is the difference between active and passive health checks?
A: Active health checks are proactive probes the load balancer sends on its own schedule, independent of real traffic, so it can detect failures even during quiet periods. Passive health checks instead observe real user traffic — for example, marking a backend unhealthy after several consecutive real requests time out or return 5xx errors — avoiding the overhead of synthetic probe traffic but only detecting problems once real requests are already failing.
Q76. What is the difference between a liveness check and a readiness check?
A: A liveness check answers "is this process still running and not deadlocked/crashed" — failing it typically triggers a restart of the instance. A readiness check answers "is this instance currently able to accept traffic" — failing it just pulls the instance out of the load balancer's rotation without restarting it, which matters for cases like a server that's alive but still warming up a cache or temporarily overloaded and needs a break, not a restart.
Q77. Show an example HAProxy active health check configuration.
A: HAProxy's option httpchk defines the HTTP request path used for probing, http-check expect defines what response counts as healthy, and per-server inter/fall/rise parameters control the probe interval and consecutive-failure/success thresholds before a state change.
backend http_back
option httpchk GET /healthz
http-check expect status 200
server app1 10.0.1.10:8080 check inter 5s fall 3 rise 2
server app2 10.0.1.11:8080 check inter 5s fall 3 rise 2Q78. What do the health check interval, timeout, fall, and rise thresholds control?
A: Interval sets how frequently a probe is sent; timeout sets how long the load balancer waits for a response before counting it as a failure. "Fall" is the number of consecutive failed checks required before marking a healthy backend down, and "rise" is the number of consecutive successful checks required before marking a down backend healthy again — tuning these balances fast failure detection against false positives from a single transient blip.
Q79. What happens operationally when a backend fails its health check?
A: The load balancer stops sending new requests to that backend immediately (typically after connection draining any in-flight requests), effectively shrinking the active pool by one, while continuing to probe it in the background. As soon as the backend passes the configured "rise" threshold of consecutive successful probes, it's automatically added back into rotation with no manual re-registration needed.
Q80. How does the circuit breaker pattern relate to load balancer health checking?
A: A circuit breaker is a client-side (or sidecar-proxy-side) safeguard that stops sending requests to a downstream service entirely once its failure rate crosses a threshold, "opening" the circuit to fail fast instead of piling up timeouts — conceptually similar to health checks but reactive to real call outcomes and often applied per-caller rather than centrally. Many service meshes combine both: passive health-check-style outlier detection to eject a bad instance from the pool, plus circuit breakers to limit how much traffic/concurrency any single caller sends downstream.
Q81. What is graceful shutdown / connection draining during a rolling deploy?
A: Graceful shutdown means an instance being terminated first signals "not ready" (failing its readiness check) so the load balancer stops routing new requests to it, waits for existing in-flight requests to complete (up to a bounded drain timeout), and only then actually shuts down the process. Skipping this step causes abrupt connection resets for any request in progress at the moment of termination, which is a common and avoidable source of deploy-time error spikes.
Q82. How do Kubernetes readiness and liveness probes affect Service/load-balancer routing?
A: A Kubernetes Service only routes traffic to pod endpoints that are currently passing their readiness probe — a failing readiness probe removes the pod's IP from the Service's endpoint list without killing the pod, exactly like a load balancer health check. A failing liveness probe instead causes the kubelet to restart the container, since it indicates the process itself is unhealthy, not just temporarily unable to serve traffic.
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 10Q83. What is a "flapping" backend and how do load balancers avoid overreacting to it?
A: A flapping backend repeatedly toggles between healthy and unhealthy states in quick succession, often due to a marginal resource issue or a noisy check endpoint, and reacting instantly to every state change would cause thrashing — constantly adding and removing the server from rotation, disrupting traffic and any sticky sessions pinned to it. Requiring multiple consecutive failures/successes (fall/rise thresholds) and sometimes applying a cooldown or "slow start" period after recovery smooths this out and prevents overreacting to noise.
Q84. What are sticky sessions (session affinity)?
A: Sticky sessions ensure that all requests from a particular client are consistently routed to the same backend server for the duration of a session, rather than being load-balanced independently per request. This matters when a server holds client-specific in-memory state (like a shopping cart or authenticated session object) that isn't shared with other backends.
Q85. How is session affinity typically implemented?
A: The two most common mechanisms are cookie-based affinity, where the load balancer sets a cookie identifying which backend handled the first request and reads it on subsequent requests, and IP-based affinity (IP hash), where the client's source IP deterministically maps to a backend. Cookie-based affinity is more accurate for clients behind shared/NAT IPs but requires the load balancer to operate at L7; IP-based works at L4 but can be thrown off by many clients sharing one visible IP.
Q86. What are the downsides of relying on sticky sessions?
A: Sticky sessions undermine even load distribution, since a server that happens to attract many "heavy" sticky clients can become overloaded while others idle, and they complicate scaling — removing a server (for a deploy or scale-down) disrupts every session pinned to it. They also make horizontal autoscaling less effective, since newly added servers won't receive any of the existing sticky traffic until new sessions start.
Q87. How do you design a service to avoid needing sticky sessions at all?
A: Make the backend stateless by externalizing session/cart/user state into a shared store (Redis, a database, or a distributed cache) that every backend instance can read and write, so any server can handle any request for any user. This is generally the preferred long-term architecture, since it removes the operational fragility and scaling limitations that sticky sessions introduce, at the cost of an extra network hop to the shared store.
Q88. Show an nginx configuration using ip_hash for session affinity.
A: The ip_hash directive inside an nginx upstream block switches the pool's algorithm from round robin to a consistent hash of the client's IP address, so repeat requests from the same client IP are routed to the same backend as long as the pool membership doesn't change.
upstream backend_pool {
ip_hash;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}Q89. What is the trade-off between session replication and a centralized session store?
A: Session replication copies each session's state to every (or several) backend instances in the cluster, so any server can serve any request without an external dependency, but it costs memory and network bandwidth proportional to cluster size and session churn, and doesn't scale well past a handful of nodes. A centralized store like Redis keeps one copy of session state that all backends query over the network, scaling much better and simplifying consistency, at the cost of adding a new dependency and a network round trip per session read/write.
Q90. What is a reverse proxy?
A: A reverse proxy sits in front of one or more backend servers and forwards client requests to them on the backend's behalf, returning the backend's response back to the client as if the proxy itself had produced it. Clients only ever interact with the proxy, never directly with the backend servers, which lets the proxy add caching, compression, TLS termination, and other cross-cutting behavior transparently.
Q91. What is the difference between a reverse proxy and a load balancer?
A: Conceptually a load balancer is a specialized reverse proxy whose primary job is distributing requests across multiple backend replicas of the same service, while a general reverse proxy's core job is simply intermediating and can front even a single backend server for benefits like caching, SSL termination, or request/response rewriting. In practice, the same software (nginx, HAProxy, Envoy) commonly performs both roles simultaneously.
Q92. What is the difference between a forward proxy and a reverse proxy?
A: A forward proxy sits in front of clients and makes requests to external servers on their behalf, typically to hide client identity, enforce content filtering, or cache outbound requests — the server being contacted doesn't know (or care) which specific client originated the request. A reverse proxy sits in front of servers and handles requests on their behalf, so it's the client that's unaware of which specific backend actually served the request.
Q93. What are common reverse proxy responsibilities besides load balancing?
A: Common responsibilities include SSL/TLS termination, response caching to reduce backend load, gzip/brotli compression, request/response header rewriting, rate limiting and basic DDoS mitigation, request logging/metrics collection, and serving static assets directly without hitting the application server at all.
Q94. Can a single nginx instance act as both reverse proxy and load balancer?
A: Yes — nginx's proxy_pass directive pointed at an upstream block with multiple servers makes it both simultaneously: it proxies (terminates the client connection and forwards on the backend's behalf) while also load balancing across the pool's members using whichever algorithm the upstream block specifies.
server {
listen 443 ssl;
server_name api.example.com;
location /api/ {
proxy_pass http://backend_pool;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}Q95. What role does a sidecar proxy (e.g., Envoy in a service mesh) play in load balancing?
A: In a service mesh, a sidecar proxy runs alongside every service instance and intercepts all its inbound/outbound traffic, performing client-side load balancing across the destination service's healthy instances (using service-discovery data rather than a centralized proxy) plus retries, circuit breaking, and mTLS. This distributes the load-balancing logic to every caller instead of funneling all traffic through one central load balancer, avoiding a single bottleneck/hop for internal service-to-service calls.
Q96. What is a CDN and what problem does it solve?
A: A CDN (Content Delivery Network) is a globally distributed network of edge servers that cache and serve content from locations physically close to end users, instead of every request traveling back to a single origin server. It solves the latency and load problems caused by geographic distance and traffic spikes — a user in Tokyo gets content from a nearby edge PoP rather than crossing an ocean to an origin server in Virginia.
Q97. What is edge caching?
A: Edge caching means storing copies of frequently requested content (images, JS/CSS bundles, API responses, video segments) on servers at the "edge" of the network, close to end users, so subsequent requests for the same content are served directly from the edge without contacting the origin at all. This reduces latency for users and dramatically cuts the request volume the origin server has to handle.
Q98. What is the difference between origin pull and origin push CDN models?
A: In origin pull (the more common model), the CDN edge fetches content from the origin server on-demand the first time it's requested, caches it according to the response headers, and serves subsequent requests from cache until it expires. In origin push, the content owner proactively uploads/publishes content directly to the CDN's storage ahead of time, which suits large static assets or video files that are known in advance rather than generated dynamically.
Q99. What is a CDN PoP (point of presence)?
A: A PoP is a physical or logical edge location — a cluster of servers in a specific city or region — where the CDN caches content and terminates client connections. CDNs operate hundreds of PoPs worldwide so that, via DNS-based or anycast routing, each user is directed to the geographically nearest one, minimizing round-trip latency.
Q100. What is cache invalidation/purging in a CDN, and why is it hard?
A: Cache invalidation (purging) forces cached content at edge PoPs to be discarded or re-validated before its TTL naturally expires, needed when the origin content changes and stale cached copies would otherwise keep being served. It's hard because the request may need to propagate to potentially hundreds of distributed PoPs, each with its own cache, and doing so instantly and consistently at global scale (rather than relying on natural TTL expiry) is operationally and technically nontrivial — which is why cache-busting via versioned URLs is often preferred over purging.
Q101. What HTTP headers control CDN caching behavior?
A: Cache-Control is the primary header — max-age sets how long a client may cache a response, and s-maxage overrides that specifically for shared caches like CDNs. ETag enables conditional revalidation (a 304 Not Modified response if the content hasn't changed), and Vary tells caches that responses differ based on a given request header (like Accept-Encoding), so they must be cached separately per variant.
Cache-Control: public, max-age=86400, s-maxage=604800
ETag: "33a64df551"
Vary: Accept-EncodingQ102. What is cache hit ratio and why does it matter for CDN cost and performance?
A: Cache hit ratio is the percentage of requests served directly from the CDN's edge cache versus those that require a "miss" round trip to the origin server. A higher hit ratio directly translates to lower latency for users (edge responses are faster) and lower load/bandwidth cost on the origin, so tuning cache keys, TTLs, and cache-control headers to maximize hit ratio is a core CDN performance-optimization task.
Q103. What is stale-while-revalidate?
A: stale-while-revalidate is a Cache-Control extension that lets a cache serve an already-expired (stale) response immediately while asynchronously fetching a fresh copy from the origin in the background for future requests. This trades brief staleness for consistently low latency, since users never have to wait synchronously for a cache-miss round trip during the revalidation window.
Q104. What is an origin shield in a CDN architecture?
A: An origin shield is a designated, single caching layer positioned between the many distributed edge PoPs and the origin server, so that on a cache miss, edge nodes fetch from the shield instead of hitting the origin directly. This consolidates redundant simultaneous origin requests from multiple PoPs (for the same newly-requested object) into far fewer actual origin hits, protecting the origin from thundering-herd load spikes.
Q105. How do CDNs accelerate dynamic (non-cacheable) content?
A: For content that can't be cached (personalized API responses, POST requests), CDNs still help via "dynamic acceleration" — using their own private, pre-warmed backbone network and optimized TCP/TLS connections between edge and origin instead of the public internet, plus techniques like connection pooling, route optimization, and TCP/TLS session reuse, which reduce round-trip latency even without caching the payload itself.
Q106. What is a signed URL/cookie used for in CDN content protection?
A: Signed URLs and signed cookies let content owners restrict access to cached CDN content — a URL or cookie is cryptographically signed with an expiration time and optional IP/path restrictions, and the CDN edge validates the signature before serving the content, rejecting requests with an invalid or expired signature. This is commonly used for paid video streaming, private downloads, or time-limited access links, without requiring every request to hit the origin for an authorization check.
Q107. What is Global Server Load Balancing (GSLB)?
A: GSLB distributes traffic across multiple data centers or regions, typically using DNS responses that vary based on factors like the requester's geographic location, measured latency, or each region's current health/capacity. Unlike a local load balancer that picks among servers in one data center, GSLB operates one level up, deciding which entire region a client should be sent to.
Q108. What is Geo-DNS / geo-routing?
A: Geo-DNS resolves the same domain name to different IP addresses depending on the geographic location of the querying resolver (inferred from its IP address), directing users to the nearest or most appropriate regional deployment. It's commonly used to comply with data-residency requirements, serve localized content, or simply reduce latency by keeping traffic within a nearby region.
Q109. What is latency-based DNS routing (e.g., AWS Route 53 latency routing)?
A: Latency-based routing selects which regional endpoint to return based on measured network latency from various points on the internet to each candidate region, rather than pure geographic distance (which doesn't always correlate with actual network latency due to routing paths and peering). Route 53 continuously maintains latency measurements between AWS regions and different parts of the internet to make this decision.
Q110. How does anycast routing provide global load balancing, and how does it differ from GSLB?
A: Anycast advertises the same IP address from multiple locations via BGP, and internet routing (not DNS) automatically sends each client's packets to the topologically nearest healthy location — the load-balancing decision happens at the network layer, transparently and near-instantly on failure. GSLB, by contrast, makes its decision at the DNS layer by returning different IP addresses to different clients, which is subject to DNS caching/TTL delay and doesn't react as instantly to an outage as anycast's BGP-level rerouting.
Q111. What is DNS-based failover and what limits its speed?
A: DNS-based failover works by health-checking each regional endpoint and updating which IP a DNS record returns when the primary becomes unhealthy, so new lookups get routed to a healthy backup region. Its speed is fundamentally limited by TTL and caching: clients and resolvers that already cached the old (now-unhealthy) IP won't re-query until that TTL expires, so failover isn't instantaneous for already-cached clients even though the authoritative record changes immediately.
Q112. How does GSLB differ conceptually from a data-center-local load balancer?
A: A local load balancer operates within a single data center or region, distributing requests across individual server instances that are all roughly equally "close" to it, and can react to failures within milliseconds since it's directly in the request path. GSLB operates across data centers/regions, deciding which entire region a client's traffic should even be directed toward, and typically works through DNS (or anycast) rather than sitting inline in every request's path.
Q113. What is the difference between active-active and active-passive high availability?
A: In active-active, multiple instances/regions all actively serve live traffic simultaneously, so capacity and redundancy are combined — losing one node just redistributes its share of load to the others. In active-passive, one instance/region serves all traffic while a standby sits idle (or serves no production traffic) ready to take over on failure; it's simpler to reason about consistency-wise but wastes the standby's capacity during normal operation and failover isn't instantaneous.
Q114. What is a floating/virtual IP, and how does VRRP/keepalived implement failover?
A: A floating (virtual) IP is an address that can be reassigned between servers, letting clients keep using one fixed IP regardless of which physical server currently owns it. VRRP (Virtual Router Redundancy Protocol), implemented by tools like keepalived, has one node act as MASTER holding the virtual IP while others act as BACKUP, exchanging heartbeat advertisements; if the MASTER stops sending heartbeats, a BACKUP promotes itself and takes over the virtual IP within seconds, typically via a gratuitous ARP announcement.
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 150
advert_int 1
virtual_ipaddress {
192.168.1.100
}
}Q115. How do you avoid the load balancer itself becoming a single point of failure?
A: Run at least two load balancer instances behind a shared floating/virtual IP (via VRRP/keepalived) or, in the cloud, use a managed load balancer service that's inherently multi-AZ and redundant (like AWS ELB, which runs across multiple availability zones by design). The goal is that the load balancer layer itself has no single instance whose failure takes down all traffic, mirroring the same redundancy principle applied to the backend servers it fronts.
Q116. What is the difference between DNS-based failover and anycast-based failover for multi-region HA?
A: DNS-based failover changes which IP address is returned to clients, but is bounded by TTL/caching delay before all clients see the change, and requires active health-check-driven record updates. Anycast-based failover keeps the same IP address everywhere and instead relies on BGP route withdrawal at the unhealthy location, so traffic reroutes to the next-nearest healthy location within the timescale of BGP convergence (often seconds), without any dependency on DNS cache expiry.
Q117. What is a split-brain scenario in an HA cluster and how is it prevented?
A: Split-brain occurs when a network partition causes multiple nodes to each believe they are the sole active primary and start accepting writes or holding the virtual IP independently, risking data divergence or IP conflicts. It's prevented with quorum-based decision making (a node only becomes primary if it can see a majority of the cluster), fencing (forcibly powering off or isolating a suspect node), and dedicated heartbeat links separate from the data network to reduce false-positive partition detection.
Q118. How does the CAP theorem relate to DNS/load-balancer failover behavior?
A: During a network partition, a distributed failover system must choose between consistency (every client sees the same, definitively correct "which node is primary" view) and availability (continuing to serve traffic even if that view might be briefly stale or disagree between nodes). DNS-based failover, quorum systems, and cached load-balancer health state all make an implicit CAP trade-off — for instance, cached-but-stale DNS answers during a region failure favor availability (old traffic still flows somewhere) over perfect consistency (everyone instantly agreeing on the new primary).
Q119. What is graceful degradation and how does it relate to load balancer design?
A: Graceful degradation means a system continues operating in a reduced-functionality mode under partial failure rather than failing completely — for example, a load balancer serving cached or default responses when all backends are unhealthy, or shedding low-priority traffic to protect capacity for critical requests. It's a deliberate design choice at the load-balancing/edge layer to fail partially and visibly rather than catastrophically and totally.
Q120. What does a safe rolling replacement of a load balancer-fronted node look like operationally?
A: First, mark the node as not-ready (fail its readiness probe or explicitly deregister it) so the load balancer stops sending new traffic to it while existing in-flight requests are allowed to drain within a bounded timeout. Only after draining completes (or the timeout expires) is the node actually terminated or updated; the replacement node then boots, passes its own health checks, and is added back into rotation — all one node at a time, so overall capacity and availability are never significantly impacted mid-rollout.
Post a Comment
Add