Netflix Backend Developer (Senior Level) - Comprehensive Interview Preparation Guide

Direct answer

Rehosting moves a system as-is onto new infrastructure and wins on speed when the goal is escaping unsupported hardware or a data center exit deadline. Replatforming makes small, targeted changes (a managed database instead of a self-hosted one) and wins when you want some operational benefit without touching application logic. Incremental refactoring decomposes and modernizes the system piece by piece and wins when the system needs to keep evolving and the team can invest in an ongoing effort. A full rewrite replaces the system outright and wins only when the existing system's structure is so far from what's needed that incremental change would cost more than starting over, and the business can tolerate the risk of an all-or-nothing delivery.

Structured elaboration

The real differentiator between these isn't just cost or time, it's what risk each one is willing to accept:

• Rehosting (lift-and-shift): lowest technical risk (nothing about the application changes), fastest to execute, but it changes nothing about the underlying problems (scaling limits, unmaintainable code, licensing costs tied to the old platform). It's a stopgap, not a fix, and it's the right first move when there's a hard deadline (end-of-life hardware, a data center closing) that leaves no time for anything deeper.
• Replatforming: moderate risk, moderate benefit. You get real operational wins (managed backups, autoscaling) without the risk of touching business logic, but you're still carrying whatever architectural debt the application has.
• Incremental refactoring: this is the strangler-fig territory, higher effort spread over a longer timeline, but continuously shippable and reversible at almost any point. It's the right choice when the system needs to keep serving traffic and evolving, and the org can sustain the discipline of an ongoing migration rather than a one-time project.
• Full rewrite: highest risk, because you're betting the whole effort on an estimate for a system whose exact current behavior nobody has fully mapped, the same problem that makes writing "characterization tests first" so important for any legacy work. It sometimes wins on relative cost and time if the existing system is small enough, or so entangled that incremental extraction genuinely doesn't have a viable seam.

Pairing the approach with a rollout strategy that matches its risk profile: rehosting and replatforming can usually go through a single cutover with a tested rollback plan, since the application behavior itself hasn't changed. Incremental refactoring needs the parallel-run and gradual-traffic-shift discipline strangler-fig migrations use. A full rewrite needs the most conservative rollout of all: extensive parallel-run validation against the old system before the new one is trusted with any real traffic, since there is no incremental fallback if a whole rewritten system turns out to be subtly wrong.

Worked example

A 15-year-old monolith running on infrastructure the vendor is discontinuing support for in six months:

• Rehost first: the deadline leaves no time for anything else, so the team moves it to modern infrastructure unchanged, buying time.
• Then decide the target: with the deadline pressure gone, they evaluate the system properly. It has clear, separable modules (billing, notifications, reporting), so incremental refactoring via strangler fig is viable, and they start extracting the highest-pain module (notifications, which changes often and causes frequent incidents) first, using canary rollout (releasing the change to a small slice of traffic first, so a problem shows up as an early warning instead of a full outage) and parallel-run validation to de-risk each extraction.
• They explicitly rule out a full rewrite: the modules are separable enough that strangling costs less in both time and risk than a rewrite would, given the amount of undocumented behavior a rewrite would have to somehow rediscover from scratch.

Trade-offs and pitfalls

The mistake that costs the most is picking based on which approach sounds most technically satisfying rather than which one matches the actual constraint (a hard deadline favors rehosting regardless of its long-term limitations; a system that genuinely cannot be decomposed favors a rewrite regardless of the risk). The second most common mistake is pairing a high-risk approach (a full rewrite) with a rollout strategy suited to a low-risk one (a single cutover), which is how a rewrite that was individually well-executed still causes an incident, because nobody validated it against real production behavior before trusting it fully.

Direct answer

Before designing, find out how the 5,000 requests per second (RPS) actually splits by region and time of day, whether traffic is single-tenant or multi-tenant with isolation requirements, and what the payment provider's own latency and reliability really are, because each answer changes whether you build one active-active deployment or several regional ones with different capacity and failover needs.

Structured elaboration

Clarifying questions and what they change

Traffic distribution changes the architecture directly

Assume, once asked, the answer comes back as 40% North America, 30% Europe, 20% Asia-Pacific, 10% elsewhere:

Assume each service instance handles 50 RPS at the target P95, with 2x headroom for burst and failover:

Without the regional split, you would size one global pool for 5,000 RPS in one place, which is both the wrong shape (traffic is not colocated) and misses the actual failover unit, which is a region, not the global total.

Latency-budget arithmetic once the provider's numbers are known

Assume component P95s: 40 ms edge/network, 30 ms auth, 40 ms inventory reservation, 50 ms fraud check, 250 ms payment provider call, 20 ms response serialization:

Against a 500 ms budget, that leaves 70 ms (14%) of margin. That margin is the number that tells you how much slower the payment provider is allowed to get before the flow must switch to an async-confirm pattern (accept the order, confirm payment out of band) rather than blowing the SLO on every request.

Trade-offs & pitfalls

• Pitfall: sizing to the global RPS total instead of the regional split; you either over-provision the small regions or under-provision the busy one.
• Pitfall: assuming the payment provider's advertised latency holds under your own peak; treat its P95 as a variable you monitor, not a constant you designed around once.
• Multi-tenant isolation is easy to forget when the ask is phrased purely in terms of aggregate RPS; a single large tenant's flash sale can consume capacity meant for everyone else unless per-tenant quotas exist.
• Choosing an async-confirm path for payment buys latency headroom but costs the user a pending state, and costs you a reconciliation or webhook path instead of a single synchronous answer.

flowchart TB
    Client --> Router[Global traffic router]
    Router --> NA[NA region: checkout service]
    Router --> EU[EU region: checkout service]
    Router --> APAC[APAC region: checkout service]
    NA --> PayNA[Payment adapter + regional store]
    EU --> PayEU[Payment adapter + regional store]
    APAC --> PayAPAC[Payment adapter + regional store]

Direct answer: A global transaction coordinator can be built two ways: as a single logical service backed by a consensus protocol like Raft or Paxos (so its own state survives node failures), or by delegating coordination to a centralized ACID database that already provides durable, consistent state. Consensus-backed coordination scales better and avoids a single database becoming the bottleneck, but costs an extra replication round-trip and more operational complexity; a centralized ACID database is simpler to reason about and operate but becomes a throughput ceiling and a single point of contention as the system grows.

Structured elaboration

Consensus-backed coordinator. The coordinator's transaction log (which participant voted what, what was decided) is replicated across an odd number of nodes via Raft or Paxos. A write only counts once a majority of replicas have durably stored it, so losing a minority of nodes (including the current leader) doesn't lose the decision, a new leader is elected and continues from the replicated log. This directly attacks 2PC's core weakness: instead of "only the coordinator knows the decision," it's "only a MAJORITY of coordinator replicas needs to know it."

Centralized ACID database as the coordinator's store. Instead of building custom replication, you let a database (itself internally replicated, e.g. via its own consensus or primary-replica mechanism) hold the coordinator's transaction table. The coordinator process is then effectively stateless: it reads/writes transaction records to the DB, and if the coordinator process itself dies, a new instance can pick up any in-flight transaction by querying the DB for records that aren't yet marked done.

Latency, throughput, complexity comparison

Worked example. A payments platform coordinating transfers across 20 account shards chose a Raft-backed coordinator cluster of 5 nodes instead of a single Postgres instance, specifically because a single Postgres instance capped them at roughly 3-4k coordinator writes/sec under their durability settings, while sharding coordinator state across a Raft-backed key range let them scale past that by adding more coordinator shards, each independently replicated. The cost was a dedicated on-call rotation for the consensus cluster that didn't exist before.

When consensus is preferred vs when a centralized DB (or plain 2PC) is still fine. Consensus-backed coordination earns its complexity when coordinator throughput or availability is itself the bottleneck, and when you already need consensus elsewhere in the system (e.g. for leader election), so you're not paying for a brand-new capability. A centralized ACID database remains the right default when transaction volume is modest, the team doesn't want to operate a consensus cluster, and the database is already a dependency the rest of the system tolerates. Plain 2PC without either (a single coordinator process with a local durable log) is fine only when the coordinator's own availability is not a differentiated requirement, i.e. a short outage of the coordinator is an acceptable cost.

Trade-offs and pitfalls. A common mistake is assuming consensus fixes 2PC's blocking problem for participants too, it only makes the COORDINATOR's decision durable and available; participants still block waiting to hear that decision, they just no longer wait for one specific fragile process to come back, they wait for a majority of a replicated cluster to answer, which is a much smaller and more bounded risk.

Direct answer

Event-driven architecture (EDA) structures a system around producers emitting events (facts that something happened) to a broker, which independently delivers them to one or more consumers, rather than a caller directly invoking another service and waiting for a response. The core trade-off versus synchronous request-response is that EDA buys loose coupling, independent scaling, and fault isolation at the cost of latency (results aren't immediate) and operational complexity (more moving pieces, harder end-to-end debugging).

Structured elaboration

Contrast with synchronous request-response. In a synchronous model, service A calls service B directly (commonly over HTTP or a remote procedure call) and blocks waiting for B's response; A knows about B specifically, and if B is slow or down, A is directly affected. In an event-driven model, A publishes an event describing what happened and moves on immediately; A does not know or care who, if anyone, consumes that event, and a consumer processes it whenever it's able to, independent of A's timing.

Core components.

• Producers: services or components that emit events when something of interest happens (an order was placed, a user updated their profile).
• Brokers: the intermediary system that receives events from producers and delivers them to consumers (examples include a managed pub/sub service or a distributed log/queueing platform); the broker decouples producers from consumers so neither needs a direct network reference to the other.
• Topics/queues: the named channels within the broker that events are published to and consumed from; a topic is typically fan-out (many consumers can each receive a copy of every event), while a queue is typically point-to-point (one message is delivered to exactly one consumer among a competing group).
• Consumers: services that subscribe to a topic or read from a queue and process the events they receive, often producing further events of their own as a result.

Typical data-pipeline use cases. Beyond application messaging, event-driven patterns are a common backbone for data pipelines specifically:

• Change-data-capture (CDC): capturing every row-level insert/update/delete in a source database as a stream of events, so downstream systems (a search index, a cache, an analytics store) stay in sync without querying the source database directly or on a slow batch schedule.
• Audit trails: because events are an immutable record of "what happened, in order," they naturally serve as an audit log, useful for compliance and for reconstructing how a piece of data reached its current state.
• Streaming enrichment: consuming a raw event stream and augmenting it with additional context (looking up a customer's segment, geocoding a location) before republishing an enriched event for downstream consumers, so that enrichment logic lives in one place rather than being duplicated by every consumer that needs it.

Trade-offs when choosing event-driven for data workloads.

• Coupling: EDA reduces coupling significantly, a producer doesn't need to know which or how many consumers exist, so new consumers can be added without changing the producer at all; synchronous designs couple the caller directly to the callee's availability and interface.
• Latency: synchronous calls give an immediate result; event-driven processing is asynchronous by nature, so there's an inherent delay (typically milliseconds to low seconds under healthy conditions, but with no hard upper bound unless explicitly engineered and monitored) between an event being produced and a consumer acting on it.
• Fault isolation: if a consumer is down or slow in an event-driven design, events queue up and are processed once it recovers, the producer and other consumers are unaffected; in a synchronous chain, a single slow or failing downstream service can cascade failure back to the caller.
• Operational complexity: event-driven systems introduce more infrastructure to run and reason about (the broker itself, delivery guarantees, ordering, retry and dead-letter handling, distributed tracing to debug a chain of asynchronous hops), which is real added complexity a purely synchronous system doesn't have to manage.

Worked example

A CDC pipeline: a relational database's write-ahead log is tailed by a CDC connector, which emits one event per row change, for example {"table": "orders", "op": "UPDATE", "id": 4821, "after": {"status": "shipped"}}, to a topic named db.orders.changes. A streaming-enrichment consumer reads that topic, looks up the customer's loyalty tier for order 4821, and republishes an enriched event to orders.enriched containing both the original change and the loyalty tier. A separate audit consumer independently reads the same db.orders.changes topic and appends every event, unmodified, to a durable audit log. Contrast this with the synchronous alternative: the order-status-update code path would need to directly call a search-index-update function, a loyalty-lookup function, and an audit-log-write function in line, meaning a bug or slowdown in any one of those three calls could block or fail the original status update itself; in the event-driven version, those three concerns are fully independent consumers of the same event, and a failure in one does not affect the others or the original write.

Trade-offs and pitfalls

The most common mistake in evaluating this trade-off is treating "asynchronous" as strictly better across the board; a workflow where the caller genuinely needs an immediate answer (checking whether an item is in stock before showing "add to cart") is usually a poor fit for a fully asynchronous redesign, since the user experience needs a synchronous response even if some other part of the system reacts to the resulting order asynchronously. A second common pitfall is underestimating the debugging cost: tracing a single business action through multiple independent consumers requires deliberate observability investment (correlation ids, distributed tracing) that a synchronous call stack gives you for free via a single request's own logs and stack trace. Event-driven data pipelines specifically also need to account for events arriving out of order or being redelivered, which a naive consumer written like a simple database trigger will not handle correctly by default.

flowchart LR
    P1[Producer] -->|publishes event| B[(Broker: topic or queue)]
    B -->|delivers event| C1[Consumer 1]
    B -->|delivers event| C2[Consumer 2]

Direct answer. Read the plan tree from the leaves up, note the join algorithm and physical operator at each level, and compare each node's estimated row count to its actual row count; the largest divergence, combined with the node consuming the most time, is almost always where you should focus first.

Structured elaboration. Start by identifying the leaves (the scans) and work upward, tracking, at each join, which side was the "outer/driving" side and which was the "inner/probed" side, and which physical algorithm was used. For each node, note actual time (cumulative, including children) and actual rows versus estimated rows. A join order that puts a large, unfiltered table on the outer side of a nested loop is a red flag; a hash join whose build side turns out much larger than estimated is a sign the memory budget for that hash table may be undersized. Once you've walked the tree once for structure, walk it again purely looking for the single node with the largest gap between estimated and actual rows, since that's usually the root cause the other symptoms trace back to.

Worked example. Suppose a plan shows, from the bottom: a sequential scan on orders with an estimated 50,000 rows and an actual 48,000 rows (a good estimate), feeding into a hash join with customers whose own estimate and actual are both close, but that hash join then feeds a nested loop join against an addresses table where the estimated row count was 10 and the actual was 12,000, executed 1,000 times in a loop. The nested loop's own local estimate wasn't wildly wrong (10 vs 12,000 estimate-vs-actual per iteration is close in absolute terms), but multiplied across 1,000 loop iterations that's the node actually dominating total time, which a glance at just its own row estimate would hide.

Trade-offs and pitfalls. It's easy to anchor on the operator name that "sounds expensive" (hash join, sort) rather than the actual numbers; a hash join over a small, well-estimated input can be nearly free, while a nested loop that LOOKS cheap per iteration can dominate total runtime once you account for how many times it runs. Always multiply per-iteration cost by loop count before deciding a node is innocent.

Direct answer: Redundancy is having extra, interchangeable components standing by so one can take over if another fails; replication is actively keeping copies of state (data) synchronized across multiple nodes so the state itself survives a failure, not just the compute that serves it. They're often used together, but they solve different problems: redundancy alone is enough for a stateless service, because any interchangeable instance can serve any request; a stateful service needs replication too, because a fresh redundant instance with no data isn't actually a working replacement.

Structured elaboration

Stateless example: a set of identical app server instances behind a load balancer, handling API requests with no local state. If one instance dies, the load balancer routes around it and an autoscaler replaces it; the new instance needs no data transfer because there was never any instance-local state to lose. This is pure redundancy: extra interchangeable copies of the same stateless computation.

Stateful example: a primary-replica database. The primary accepts writes; replicas continuously receive a copy of the write stream (replication). If the primary fails, a replica is promoted to take over. Unlike the stateless case, simply having an extra database instance running (redundancy alone, no replication) would give you an empty database, not a working replacement, because there's no mechanism copying the actual data into it.

A failure mode redundancy alone doesn't protect against, for the stateful case: data loss or corruption on the primary itself. If the primary's disk corrupts a row, or a bad write silently corrupts application-level data, having a redundant (but not yet caught-up, or synchronously replicating that same bad write) standby doesn't help, because either the standby doesn't have the data yet (async lag) or it faithfully replicated the corruption along with everything else (synchronous replication of a logically bad write). Redundancy protects against a node dying; it does not protect against the data itself being wrong, that requires backups (a separate, point-in-time copy decoupled from live replication) and, for silent corruption specifically, checksums or application-level validation.

How this generalizes: a useful mental checklist for fault tolerance covers five distinct techniques, and redundancy and replication are only two of them: retries (recover from a transient failure by trying again), bulkheads (isolate one failure from spreading to unrelated resources), failover (the mechanism that switches traffic to a healthy replacement), redundancy (having that replacement exist at all), and replication (making sure the replacement actually has the state it needs). A strong answer names which of these a given design decision is actually addressing, since "redundancy" gets used loosely to mean all five in casual conversation.

Trade-offs & pitfalls

• Replication has a cost redundancy alone doesn't: network bandwidth, storage for extra copies, and a consistency model to reason about (synchronous replication costs write latency; asynchronous replication risks data loss on failover, the classic RPO trade-off).
• A common wrong turn: assuming "we have 3 replicas" automatically means "we're protected," without checking replication lag. A replica that's minutes behind at failover time silently loses however much data arrived in that window, unless the promotion logic explicitly accounts for lag and refuses to promote a too-far-behind replica.
• Redundancy for stateless services is comparatively cheap and low-risk to over-provision; replication for stateful services is not, since more replicas means more write-path coordination overhead (for synchronous replication) or more divergence risk (for asynchronous/multi-leader), so it isn't a "just add more" lever in the same way.

Direct answer

stale-while-revalidate lets a client serve an expired cached response immediately while fetching a fresh copy in the background, and stale-if-error lets it keep serving that stale copy if the fresh fetch fails, trading a small amount of guaranteed freshness for consistently low latency and resilience to brief origin outages.

Structured elaboration

• stale-while-revalidate: Cache-Control: max-age=60, stale-while-revalidate=30 means the response is fresh for 60 seconds, and for an additional 30 seconds after that, a client (or content delivery network, CDN) can serve the stale copy immediately while triggering a background revalidation request; the NEXT request after that window gets the freshly revalidated copy.
• stale-if-error: stale-if-error=300 tells the client/CDN that if the origin is unreachable or returns an error during revalidation, keep serving the stale copy for up to 300 seconds rather than surfacing the error to the user; this converts a brief origin outage into a slightly-stale-but-working experience instead of a hard failure.
• When to recommend these: an API endpoint needing low latency but able to tolerate slightly stale responses during origin outages (news feeds, non-critical dashboards, catalog listings) is a strong fit; both directives explicitly trade a bounded amount of staleness for availability and latency, which must be an acceptable trade for the specific data.
• Behavior in normal operation vs. origin failure: in normal operation, the client mostly experiences fast responses with background-refreshed freshness (never blocking on a slow origin fetch on the critical path); during an origin failure, the same mechanism seamlessly extends the "acceptable stale window," so users experience continuity rather than an outage.
• Implementing with cache-aside: cache-aside can approximate the same behavior in application code (check cache; if within the stale-but-usable window, return immediately and kick off an async refresh; if the refresh fails, keep serving the existing value) even without a content delivery network that natively supports these headers.

Worked example

An API returning a news feed sets Cache-Control: max-age=30, stale-while-revalidate=60, stale-if-error=3600. Most requests within the first 30 seconds get a guaranteed-fresh response; requests between 30 and 90 seconds after the last fetch get an immediate stale response while a background revalidation happens; if the origin is down, the client keeps serving that stale response for up to an hour rather than failing outright, giving the origin a full hour to recover before user-facing errors would appear.

Trade-offs and pitfalls

Setting stale-if-error too long risks masking a real, ongoing outage from users (and from monitoring that relies on user-facing errors as a signal) for far longer than intended; pair a generous stale-if-error window with independent origin-health monitoring, not just user-facing symptoms. These directives are a poor fit for data where even a brief staleness window during revalidation is unacceptable (e.g., a live auction price); apply them selectively, not as a blanket default across every endpoint.

Direct answer
For a CPU spike causing timeouts: containment is isolating the affected host or throttling the traffic causing the spike so the problem stops spreading to healthy instances; mitigation is shedding non-critical load or scaling out so timeouts stop for most users even before you know the root cause; recovery is restoring the service to its normal capacity and confirming latency has genuinely returned to baseline, not just dropped once.

Structured elaboration

• Containment answers 'how do I stop this from getting worse.' For the CPU spike: pull the overloaded instance out of the load balancer pool so it stops receiving new traffic and can't drag healthy instances down with it (for example through a shared connection pool or retry storm). Safety check: confirm the load balancer has enough remaining healthy capacity before pulling the instance, or you've just made the outage worse for everyone else.
• Mitigation answers 'how do I reduce what customers feel right now,' independent of understanding the root cause yet. For the CPU spike: shed non-critical requests (defer background jobs, disable an expensive feature) or scale out horizontally to spread load. Safety check: shedding load has to be reversible and clearly logged, so nobody forgets a feature is disabled after the incident ends.
• Recovery answers 'is the service actually back to normal.' For the CPU spike: bring capacity back to its normal level, watch CPU and latency hold at baseline for a sustained window, and re-enable anything that was shed. Safety check: recovery isn't declared on a single good data point, since a transient dip can look like recovery for a minute and then relapse.

Worked example
Suppose CPU on the affected instance is pinned at 95% and p99 latency has risen from a normal 120ms to 4 seconds, causing client-side timeouts. Containment: the on-call engineer removes the instance from the load balancer pool, redistributing its traffic across the remaining healthy instances. Mitigation: because the remaining instances are now each carrying more load, they scale out from 4 to 6 instances and temporarily disable a CPU-heavy recommendation feature; CPU across the fleet drops to a more sustainable 60% and p99 latency returns to around 300ms, well below the timeout threshold even if not yet fully back to baseline. Recovery: once the root cause (an inefficient query introduced by a recent deploy) is identified and fixed, the team restores the original instance count, re-enables the recommendation feature, and watches p99 latency hold near 120ms for 30 minutes before declaring the incident resolved.

Trade-offs and pitfalls
Containment that's too aggressive (pulling too many instances, or isolating a component that other services still depend on) can turn a partial degradation into a full outage; containment that's too narrow (missing that the real blast radius includes a shared resource like a connection pool or cache) leaves the spread unaddressed. Mitigation can also mask the symptom in a way that delays real diagnosis: shedding load makes CPU look healthy again, but if nobody tracks that the shed feature is still disabled, the team can lose track of what 'fully recovered' actually means. The general pattern (same containment options: read-only mode, feature toggles, traffic shaping, or temporary scaling) applies just as well to a database write-outage as it does to a CPU spike; the phase you're in, not the specific technology, determines what action is appropriate.

Direct answer

exists_path_with_max_edge is a plain reachability question on a filtered graph: build (implicitly) the subgraph containing only edges with latency $\le L$, and run breadth-first search (BFS) or depth-first search (DFS) from src looking for dst. This costs $O(V+E)$ per call. For answering MANY threshold queries against the SAME fixed graph, that per-query cost is wasteful; the right preprocessing is to compute the minimum bottleneck value between src and dst once (the smallest $L$ for which a path exists at all), after which every future query collapses to a single comparison.

Structured elaboration

Single query. Filter edges by w <= L during traversal (no need to materialize a separate filtered adjacency list), and stop the instant dst is reached.

Many queries, one fixed graph: the minimum bottleneck path. The minimum $L$ for which src and dst become connected using only edges $\le L$ is exactly the maximum edge weight on the graph's MINIMUM BOTTLENECK PATH between them, a well-known quantity computable via a Kruskal-style sweep: sort all edges ascending by weight, union their endpoints one at a time with a union-find (disjoint-set) structure, and the moment src and dst land in the same component, that edge's weight is the answer. This is the same sweep Kruskal's algorithm uses to build a minimum spanning tree, applied here purely for its src-dst connectivity byproduct rather than for the whole tree.

Once that single value, call it bottleneck(src, dst), is known, every future exists_path_with_max_edge(L) query becomes L >= bottleneck(src, dst), an $O(\alpha(n))$ union-find lookup (already paid for during preprocessing) instead of a fresh $O(V+E)$ traversal, where $\alpha$ is the inverse Ackermann function (effectively constant for any practical input size).

Worked example

from collections import deque
from typing import Dict, List, Tuple

def exists_path_with_max_edge(adj: Dict[int, List[Tuple[int, float]]], src: int, dst: int, L: float) -> bool:
    # DFS/BFS restricted to edges with latency <= L. O(V+E) per call.
    if src == dst:
        return True
    visited = {src}
    q = deque([src])
    while q:
        u = q.popleft()
        for v, w in adj.get(u, []):
            if w <= L and v not in visited:
                if v == dst:
                    return True
                visited.add(v)
                q.append(v)
    return False

class UnionFind:
    def __init__(self, n):
        self.parent = list(range(n))
        self.rank = [0] * n
    def find(self, x):
        while self.parent[x] != x:
            self.parent[x] = self.parent[self.parent[x]]
            x = self.parent[x]
        return x
    def union(self, a, b):
        ra, rb = self.find(a), self.find(b)
        if ra == rb:
            return
        if self.rank[ra] < self.rank[rb]:
            ra, rb = rb, ra
        self.parent[rb] = ra
        if self.rank[ra] == self.rank[rb]:
            self.rank[ra] += 1

def min_bottleneck(n: int, edges: List[Tuple[int, int, float]], src: int, dst: int) -> float:
    # Smallest L such that src and dst connect using only edges <= L.
    if src == dst:
        return float("-inf")
    uf = UnionFind(n)
    for u, v, w in sorted(edges, key=lambda e: e[2]):
        uf.union(u, v)
        if uf.find(src) == uf.find(dst):
            return w
    return float("inf")  # never connects at any threshold

if __name__ == "__main__":
    adj = {
        0: [(1, 5.0), (2, 1.0)],
        1: [(3, 2.0)],
        2: [(1, 1.0), (3, 9.0)],
        3: [],
    }
    print("path 0->3 with L=8 (blocks the 9.0 edge):", exists_path_with_max_edge(adj, 0, 3, 8.0))
    print("path 0->3 with L=1.9 (blocks the 2.0 edge too):", exists_path_with_max_edge(adj, 0, 3, 1.9))
    print("path 0->3 with L=2.0 (0-2-1-3, all edges <= 2.0):", exists_path_with_max_edge(adj, 0, 3, 2.0))

    edges = [(0, 1, 5.0), (0, 2, 1.0), (1, 3, 2.0), (2, 1, 1.0), (2, 3, 9.0)]
    bn = min_bottleneck(4, edges, 0, 3)
    print("minimum bottleneck threshold for 0->3:", bn)

    candidate_Ls = sorted(set(w for _, _, w in edges))
    smallest_true_L = next(L for L in candidate_Ls if exists_path_with_max_edge(adj, 0, 3, L))
    print("Smallest L (by brute-force scan) where path exists:", smallest_true_L)
    print("Matches min_bottleneck result:", smallest_true_L == bn)

    queries = [0.5, 1.0, 1.9, 2.0, 9.0]
    results = [(L, L >= bn) for L in queries]
    print("Batch query results (L, exists_path):", results)
    ref_results = [(L, exists_path_with_max_edge(adj, 0, 3, L)) for L in queries]
    print("Matches per-query BFS re-verification:", results == ref_results)

Output (actually executed with python3):

path 0->3 with L=8 (blocks the 9.0 edge): True
path 0->3 with L=1.9 (blocks the 2.0 edge too): False
path 0->3 with L=2.0 (0-2-1-3, all edges <= 2.0): True
minimum bottleneck threshold for 0->3: 2.0
Smallest L (by brute-force scan) where path exists: 2.0
Matches min_bottleneck result: True
Batch query results (L, exists_path): [(0.5, False), (1.0, False), (1.9, False), (2.0, True), (9.0, True)]
Matches per-query BFS re-verification: True

The batch-query results, computed purely from the precomputed bn via a comparison, are cross-checked against re-running the full BFS-based exists_path_with_max_edge for each threshold independently; the two agree on all 5 queries, confirming the preprocessing trick is not just faster but exactly equivalent to repeated brute-force checks.

Complexity

exists_path_with_max_edge: time $O(V+E)$ per call, space $O(V)$ for the visited set. min_bottleneck: time $O(E \log E)$, dominated by the sort (the union-find sweep itself is $O(E \alpha(V))$, negligible next to the sort); space $O(V)$ for the union-find parent and rank arrays. Once min_bottleneck is precomputed, each subsequent threshold query is $O(1)$.

Edge cases

• src == dst: exists_path_with_max_edge returns True immediately; min_bottleneck returns $-\infty$, correctly signaling "no threshold is even needed."
• No path at any threshold: min_bottleneck returns $+\infty$ after the sort exhausts without ever merging src and dst's components.
• L exactly equal to an edge's weight: the <= comparison in exists_path_with_max_edge includes that edge, consistent with min_bottleneck returning that same weight as the exact threshold where the path first becomes possible.
• Disconnected graph with src and dst in different components entirely: both functions correctly report no path regardless of how large L is.

Trade-offs and pitfalls

• When preprocessing pays off. Computing min_bottleneck costs $O(E\log E)$ (dominated by the sort). For a single query, that is strictly worse than the $O(V+E)$ direct BFS. The preprocessing wins once the number of future queries against the SAME (src, dst) pair, or more usefully, the same graph with varying src/dst pairs (which needs a slightly different structure, see below), is large enough to amortize the one-time sort cost.
• Extending to many (src, dst) pairs, not just many thresholds for one pair. The Kruskal-style union-find sweep, run once, actually answers "what is the bottleneck between ANY pair of nodes" simultaneously: as the sweep proceeds, every time two components merge, every existing pair across the two components gets its bottleneck value fixed at that merge's edge weight. This is the classic minimum bottleneck spanning tree property, and it generalizes cleanly to an offline batch of many (src, dst, L) queries processed in one pass, not just repeated queries for one fixed pair.
• Common mistake: assuming the minimum bottleneck path is the same as the shortest (minimum total weight) path. They are different optimization criteria: minimum bottleneck minimizes the single WORST edge on the path, while shortest path minimizes the SUM of edges; a path can be bottleneck-optimal while having a much larger total latency than an alternative route, or vice versa.
• Common mistake: re-sorting edges inside every call to min_bottleneck when it is invoked repeatedly for different (src, dst) pairs on the same graph. The sorted edge list and the union-find state built while sweeping it are graph-level, not query-level, information; a production version should build the sorted structure once and either replay the sweep or use an offline batch technique (small-to-large union-find with online queries answered at merge time) rather than resorting on every call.
• Directed graphs. The union-find approach as written assumes undirected connectivity; a directed version of "path using only edges $\le L$" needs an actual directed reachability check (BFS/DFS respecting edge direction) per candidate threshold, or a more involved offline structure, since union-find inherently models symmetric (undirected) connectivity.

Purpose of replication: improve read scalability, availability, and disaster recovery by maintaining copies of data across nodes.

Leader-follower (master-slave)

• Use cases: read scaling via replicas, simple failover.
• Consistency: primary is authoritative; followers are typically eventually consistent.
• Conflicts: rare (writes only to leader); main issue is replica lag.
• Failover: promote a follower to leader; requires failover orchestration and possible data loss if replica was behind.
• Operational concerns: monitor replication lag, backups, automated failover tools, and connection rerouting.

Multi-leader (multi-master)

• Use cases: geo-distributed writes, high availability with local write endpoints.
• Consistency: concurrent writes can conflict; often eventual consistency or explicit conflict resolution.
• Conflicts: write-write conflicts require resolution strategies (last-writer-wins, vector clocks, application logic).
• Failover: nodes remain writable; partition tolerance depends on conflict handling.
• Operational concerns: increased complexity, testing of conflict resolution, global schema changes are harder, and higher risk of data anomalies.

As a backend developer, pick leader-follower for most apps needing strong single-writer semantics; use multi-leader only when geo-local writes and low-latency local writes outweigh the complexity of conflict handling.