FAANG-Standard Backend Developer (Mid-Level) Interview Preparation Guide

Direct answer

Atomic multi-service reconciliation over a dependency graph needs the SAME "all succeed or safe rollback" guarantee a database transaction provides, but GitOps has no equivalent of a database's native transaction mechanism, each service's manifests apply independently through the underlying Kubernetes API, so the operator has to construct that guarantee itself: track each service's individual reconciliation status against the dependency graph's required ORDER, and on ANY service's failure, actively COMPENSATE (roll back) every service that had already succeeded in this same multi-service change, rather than leaving a partially-applied graph in an inconsistent state.

Structured elaboration

Data model. A MultiServiceChange custom resource capturing: the SET of services involved in this specific coordinated change, their DEPENDENCY ORDER (a directed acyclic graph, service B cannot reconcile until service A, which it depends on, has succeeded), each service's OWN manifest reference (a Git commit/digest), and, critically, each service's PRIOR successful state (the last known-good manifest reference for that service, needed as the compensation target if a rollback becomes necessary).

Reconciliation loop. Processes services in DEPENDENCY ORDER (a topological sort of the graph), reconciling each only once its dependencies have themselves reached a succeeded state; this is the mechanism that gives ordering guarantees a plain, independent per-service reconciliation loop does not provide on its own.

Handling of partial failures. If a service in the middle of the ordered sequence FAILS to reconcile (after its own bounded retry), the operator does NOT continue reconciling the REMAINING, not-yet-processed services in the graph (since they may depend on the failed one, and even if they don't directly, the overall multi-service change is now incomplete); it transitions the MultiServiceChange to a compensating state and begins rollback.

Rollback/compensation semantics. Roll back every service that ALREADY succeeded in THIS multi-service change, in REVERSE dependency order (a service's dependents must be rolled back before the service itself, mirroring the forward order's own logic), reverting each to its recorded PRIOR successful state (not simply "delete," since the prior state may itself be a specific, meaningful configuration, not merely "nothing"); the never-reconciled remaining services in the graph need no compensation at all, since they were never actually changed.

Worked example

A MultiServiceChange spanning three services with dependency order network-policy before auth-service before checkout-service (checkout depends on auth, auth depends on the network policy being in place first):

1. network-policy reconciles successfully first (no dependencies).
2. auth-service reconciles successfully second (its dependency, network-policy, already succeeded).
3. checkout-service FAILS to reconcile (its new manifest references a config value that does not exist yet).
4. The operator transitions to compensating: rolls back auth-service to its PRIOR successful manifest first (checkout, the failed one, was never actually applied, so it needs no rollback, just needs to stop being retried), then rolls back network-policy to its prior state.
5. Final state: all three services back at their PRE-CHANGE configuration, a clean, fully-compensated failure, rather than network-policy and auth-service left on their NEW configuration while checkout alone failed, which would have been a genuinely inconsistent, partially-migrated state.

Trade-offs and pitfalls

• Common mistake: rolling back services in the SAME order they were applied, rather than REVERSE dependency order. Per the worked example, rolling back network-policy (which auth-service depends on) WHILE auth-service is still running its new configuration risks auth-service operating against a network policy that no longer matches what it expects, briefly recreating the exact kind of inconsistency the whole compensation mechanism exists to avoid; reverse-order rollback (dependents first, dependencies last) is what keeps every INTERMEDIATE state during the rollback itself consistent too, not just the final state.
• "Roll back to the prior successful state" requires that prior state to have actually been RECORDED before the new change began, an operator that only tracks the CURRENT desired state, with no memory of what preceded it, cannot perform this rollback at all; this is a real, easy-to-omit data-model requirement, not an implementation detail.
• A service that was never reached in the forward pass (because an earlier dependency failed first) needs NO compensation, per the worked example's checkout-service, attempting to "roll back" a service that was never actually changed is at best a wasted no-op and at worst risks touching a resource the operator has no legitimate reason to be modifying right now.
• This entire mechanism assumes the dependency graph itself is ACCURATE and complete: a graph missing a real dependency risks reconciling (or worse, considering "successful") a service whose actual prerequisite was never satisfied, defeating the ordering guarantee the whole design exists to provide.

Direct answer. A standard B-tree index stores values in sorted order, which lets it efficiently find a matching PREFIX of a string; a wildcard at the START of a LIKE pattern means there's no fixed prefix to search for, so the index can't narrow the search at all and the engine falls back to checking every row's text against the pattern directly.

Structured elaboration. LIKE 'foo%' (wildcard only at the end) can use a standard B-tree index efficiently, because every string matching that pattern shares the same prefix, 'foo', which the index's sorted order can jump straight to. LIKE '%foo%' or LIKE '%foo' (wildcard at the start) has no such fixed prefix: a match could be any string CONTAINING or ENDING WITH 'foo' anywhere, which the sorted order of a standard index gives no leverage on at all, so the engine has no better option than scanning and checking every row.

Realistic options: a specialized full-text search index (built for token or substring matching rather than prefix matching) is the most direct fix if your engine supports one and the matching semantics fit; a trigram or n-gram index (where supported) can accelerate substring matches specifically, including leading-wildcard patterns, by indexing small overlapping fragments of the text rather than the whole string; and, if the real requirement is closer to "search," moving that specific workload to a dedicated search engine designed for it is often the more durable long-term answer once a standard relational index genuinely can't help.

Worked example. A dashboard filter doing WHERE comments LIKE '%refund%' against a large text column is the exact shape that defeats a plain B-tree index; if the underlying database supports a trigram index, adding one on that column can make this specific kind of substring search dramatically faster without changing the query at all, since the trigram structure is built specifically to handle "the pattern could start anywhere" searches that a standard index can't.

Trade-offs and pitfalls. Specialized indexes for this kind of search (trigram or full-text) cost more storage and more write-time maintenance than a standard B-tree, and aren't a good fit for every use case (very short strings, or a genuinely rare query pattern that doesn't justify the ongoing cost); weigh how often this kind of search actually runs, and how latency-sensitive it is, against that ongoing cost before reaching for a specialized index.

Direct answer

Compressing a three-month ramp into three weeks means deliberately not becoming broadly competent and instead becoming narrowly reliable on exactly what the project needs, while being explicit about what I'm skipping and how the resulting gap gets covered, whether that's a reviewer, a narrower scope, or stated uncertainty on anything I can't fully back. I would never let three weeks of learning quietly pass as equivalent to three months; the compression only works if everyone downstream knows what they're actually getting.

What compression actually means

Triage by what the project needs, not by the team's usual onboarding order. A normal three-month ramp typically builds broad familiarity before depth. With three weeks, I invert that: identify the two or three things this specific project actually requires me to be right about, and go deep only there, accepting shallow or absent knowledge everywhere else. If the timeline compressed further, to a single day, the triage gets sharper still: I would ask what one piece of context, if I got it wrong, would sink the project, and spend almost all the time there, explicitly skipping everything else rather than spreading thin.

Name the quality bars I refuse to drop even under compression. Compression is about learning less, not about shipping unverified work. I would still hold the same review and testing standards for anything I produce, even if the compressed ramp buys speed on learning but never on care.

Lean on other people's time, and be honest about the cost. The fastest lever available is borrowing a domain expert's attention instead of self-teaching everything from scratch, but that time is not free. I would be specific with the team about how much of someone's time I'm asking for and for how long, rather than letting it show up later as their own work quietly slipping.

Cover the gap with structure, not bravado. Where I know I'm still shallow, I build in a mandatory review step, narrow the scope of what I own until I catch up, or explicitly flag deliverables as carrying more uncertainty than the team's usual standard, rather than letting a compressed ramp quietly lower the bar without anyone deciding that on purpose.

Worked example

Joining a project three weeks before a launch, with the team's usual ramp closer to three months, I asked the lead directly what single area, if I got it wrong, would actually hurt the launch. The answer was one integration point with a partner system, so I deliberately left everything else about the surrounding codebase thin. I spent roughly half of the three weeks almost entirely on that integration, pairing daily with the engineer who owned it, which meant asking for about six hours a week of her time, made explicit up front rather than assumed. For the parts I stayed shallow on, I did not pretend otherwise: I flagged two areas in my own handoff notes as reviewed by me but not independently verified, and asked for an extra reviewer on anything touching them until I had more time. The launch shipped on schedule; the cost was that a change I made in one of the flagged areas weeks later took noticeably longer because I was still building real familiarity with it, a cost I had knowingly deferred rather than avoided.

Trade-offs and pitfalls

The core trade-off is depth for speed: three weeks buys narrow reliability, not the broad judgment three months would have given, and pretending otherwise is the real risk, not the compression itself. The most common pitfall is letting the compressed timeline quietly lower quality bars along with breadth, when only breadth should be sacrificed. A second pitfall is treating borrowed expert time as free; if it isn't planned and bounded, the person you leaned on absorbs the cost you didn't.

Direct answer: Break the project into its major components or workstreams, and for each say plainly whether you owned it, contributed to it, or reviewed it, backed by something concrete you can point to rather than blanket language like "we" or "helped."

Why interviewers ask this

They're checking whether you can isolate your individual contribution inside a team effort, and whether your language ("I" versus "we") tracks something real rather than blending your work with everyone else's.

A simple ownership vocabulary

How to structure the answer

1. Break the project into 3-5 components (for example: scope and requirements, the core build, testing, rollout, monitoring).
2. Label your involvement per component using the vocabulary above.
3. Pick one component you owned and be ready to go deep on it, since that's what actually proves the claim rather than just asserting it.

Worked example (illustrative skeleton)

A cross-functional launch project broken into four components: requirements and scope (contributed: shaped 2 of 6 requirements after running user interviews), the core feature build (owned: built and shipped it end to end), rollout communication (supported: wrote the release notes, didn't own the go/no-go decision), and post-launch monitoring (owned: set up the alert that caught a regression). The rollout itself was staged from 10% of users to 100% over three weeks; the monitoring alert flagged the regression during the first week, while the remaining 90% of users hadn't yet been exposed to the change.

Trade-offs and pitfalls

• Overclaiming ("I built the whole thing") when you contributed one piece invites a follow-up you can't sustain once the interviewer asks for detail.
• Underclaiming ("we did everything together") reads as no real individual ownership at all.
• Not having one component ready to go deep on undermines the whole answer.
• Being honest about where you were a contributor rather than the owner builds credibility; it doesn't weaken the answer.

Direct answer

Sponsorship means spending your own credibility to open a door someone couldn't open for themselves, which is different from mentoring, which is advice given directly to the person. The core act is advocating for them by name in a room they aren't in, backed by specific, evidence-based reasons they deserve the opportunity.

What sponsorship requires

Political capital and timing, not just advice. Mentoring can happen anywhere, anytime, one on one. Sponsorship requires actually being present, or having enough standing, in the room where a real decision gets made: a promotion committee, a staffing decision, an assignment to a high-visibility project.

An evidence-backed case, not a vague endorsement. "They're great" doesn't move a room. Specific, concrete contributions you can vouch for personally do. Building this case ahead of time, before the opportunity comes up, is part of the work.

Deciding when it's warranted. The right moment is when someone is already delivering at the target level but lacks the visibility or exposure to be considered for it, there's a real decision window open, and you have enough credibility in that specific room for your advocacy to actually carry weight.

Making the specific ask. Vouching in general terms is weaker than naming the specific opportunity and asking for the specific outcome: this person, for this role, on this team, now.

Aftercare. Sponsorship only compounds if the person knows it happened. Telling them what you did lets them lean into the opportunity and know someone is actively in their corner, not just quietly hoping things work out. Following up on the outcome, win or not, matters too.

Worked example

Someone you work closely with does excellent work but has almost no visibility outside their immediate team. A high-visibility opportunity, or a promotion cycle, comes up in a room they aren't part of. You go in with specific, concrete contributions you can personally back, not general praise, and explicitly vouch for their readiness for that specific opportunity. Afterward, they're included in the opportunity or the promotion conversation, and you tell them directly what you did and why, rather than letting them find out secondhand or not at all.

Trade-offs and pitfalls

Sponsoring someone whose work you can't concretely back with specifics spends your credibility on hope rather than evidence, and if it doesn't pan out, it costs you standing in that room for the next person you'd want to sponsor.

Sponsoring quietly and never telling the person defeats much of the point. They don't know to lean into the opportunity, and they don't know someone is actively advocating for them, which is often as valuable as the opportunity itself.

Sponsorship is finite. You have a limited amount of credibility to spend across your whole network, which means you genuinely cannot sponsor everyone equally, and who you choose to spend it on is a real, sometimes uncomfortable decision worth being honest with yourself about.

A common confusion is treating a glowing performance review comment as sponsorship. Real sponsorship requires actually being in the room, advocating for a specific decision, not just praising someone in the abstract where it doesn't reach the decision-maker.

Direct answer

(a) City road routing with non-negative weights and frequent repeated queries: Dijkstra's algorithm as the baseline, but for a system serving many queries against a largely static road network, layer on precomputation (Contraction Hierarchies or a bidirectional/ALT search) rather than running plain Dijkstra fresh per query. (b) A currency exchange graph where arbitrage implies negative cycles: Bellman-Ford, specifically because it is the standard algorithm that both handles negative edge weights and can detect a negative cycle's existence, which is the actual signal being searched for (an arbitrage opportunity IS a negative cycle in a graph where edge weights are the negative log of exchange rates). (c) Pairwise social network distances on unweighted graphs: breadth-first search (BFS) from each source, since with unweighted edges the fewest-edges path IS the shortest path, and BFS finds it in strictly less work than any weighted algorithm would need to do.

Structured elaboration

(a) City road routing. Every edge weight is non-negative (travel time or distance cannot be negative), which is exactly Dijkstra's precondition. For a ONE-OFF query, plain Dijkstra with a binary heap is $O((V+E) \log V)$ and is the right default. For a system answering MANY queries against a road network that changes rarely (new roads open occasionally; traffic-based weight updates happen far more often than the topology itself changes), the standard production approach precomputes shortcuts once (Contraction Hierarchies) so that individual queries run in a fraction of the cost of a from-scratch Dijkstra, or uses bidirectional search (searching simultaneously from both source and destination and stopping when the two frontiers meet) to roughly halve the effective search radius. The key judgment call the question is testing: recognizing that "frequent queries" changes the right answer from "which single-query algorithm" to "what should be precomputed once, before any query arrives."

(b) Currency arbitrage. Model each currency as a node and each exchange rate as a directed edge weighted by $-\log(\text{rate})$. Under this transform, a product of exchange rates greater than 1 (a profitable arbitrage loop) becomes a SUM of edge weights less than 0 (a negative cycle), because $\log$ turns multiplication into addition and the sign flip turns "greater than 1" into "less than 0." Dijkstra cannot be used here at all: it assumes non-negative weights and produces silently wrong results (not even a detectable error) if given negative edges, because its greedy "finalize the closest unvisited node" strategy assumes no later relaxation could ever improve an already-finalized node, an assumption negative edges break. Bellman-Ford handles negative edges correctly by relaxing every edge up to $V-1$ times, and its cycle-detection extension (checking whether any edge can still be relaxed on a $V$-th pass) is exactly the mechanism for detecting that a negative cycle, and therefore an arbitrage opportunity, exists.

(c) Unweighted social-network distances. With every edge implicitly weight 1, Dijkstra still gives the correct answer but does unnecessary work maintaining a priority queue and comparing distances that could only ever increase by exactly 1 per edge. BFS achieves the same correct shortest-path distances using a plain FIFO queue, exploiting the fact that BFS naturally visits nodes in increasing order of edge count, which is precisely the shortest-path order when every edge costs the same.

Worked example

Complexity comparison, $V$ = number of nodes, $E$ = number of edges:

Concrete arbitrage instance for (b): three currencies USD, EUR, JPY with exchange rates USD to EUR = 0.9, EUR to JPY = 130, JPY to USD = 0.0086. The round-trip product is $0.9 \times 130 \times 0.0086 = 1.0062$, greater than 1, meaning one unit of USD converted around the full loop back to USD returns 1.0062 units, a 0.62 percent arbitrage. Under the negative-log transform: edge weights become $-\ln(0.9) \approx 0.1054$, $-\ln(130) \approx -4.8675$, $-\ln(0.0086) \approx 4.7560$, summing to $0.1054 - 4.8675 + 4.7560 = -0.0061$, which matches $-\ln(1.0062) \approx -0.0062$ (the small residual is rounding in the 4-decimal edge weights). A negative cycle total, matching the arbitrage: a negative sum of log-weights corresponds to a product greater than 1.

Trade-offs and pitfalls

• Common mistake: reaching for Dijkstra in scenario (b) because "it's the standard shortest-path algorithm." Dijkstra's core greedy step, permanently finalizing the shortest known distance to a node once popped, is provably wrong in the presence of negative edges, since a later negative edge could still improve a distance that was already treated as final. This is not a performance trade-off, it is a correctness failure, and it fails silently (no exception, no error) rather than crashing, which makes it a genuinely dangerous mistake to make in a financial context.
• Common mistake: reaching for Bellman-Ford in scenario (c) "to be safe." It gives the correct answer but at $O(VE)$ instead of BFS's $O(V+E)$, a real cost difference at scale on a large social graph, for no benefit since there are no negative weights to worry about.
• Common mistake in scenario (a): treating "frequent queries" as irrelevant to the algorithm choice. A system that reruns plain Dijkstra from scratch for every query is leaving a large, well-known optimization on the table (precomputation amortized across queries) that specifically becomes worthwhile once query volume is high enough to justify the one-time preprocessing cost.
• The negative-cycle DETECTION step in scenario (b) is not optional flavor, it is the actual point of the exercise: finding shortest paths in a graph that HAS a negative cycle is not even well-defined (you could loop the cycle infinitely to make the "shortest path" arbitrarily negative), so the correct behavior is to detect and report the cycle's existence, not to return some finite distance as if the graph were well-behaved.

Direct answer

Assign each arriving task to whichever machine currently has the smallest total load (the "least-loaded machine" greedy rule, also called list scheduling). This online rule is never worse than twice the optimal offline makespan, and a short exchange-style argument tightens that to a factor of $\left(2 - \frac{1}{m}\right)$, where m is the number of identical machines. This is the classical Graham's bound (1966). If tasks additionally carry hard deadlines, a single machine's feasibility is best handled separately by Earliest Deadline First (EDF); no online multi-machine rule offers a comparable constant-factor guarantee once deadlines are layered on top of load balancing.

Structured elaboration

Setup: m identical machines, tasks arrive one at a time with processing time $p_i$, no knowledge of future arrivals, goal is to minimize the makespan (the finish time of the last task to complete).

Greedy rule: on each arrival, place the task on the machine with the current minimum cumulative load.

The exchange/potential argument for the bound. Let job j be the one that finishes last in the greedy schedule, running on machine i, starting at time t. Because greedy always routes work to whichever machine has the least load at that instant, every OTHER machine's load at time t must already be at least t (otherwise greedy would have picked one of them instead). Summing that lower bound across all m machines: the total work already placed before job j arrived, $P - p_j$ (where P is the sum of all processing times), is at least $m \cdot t$. That gives:

using two separate lower bounds on any optimal schedule's makespan: the average load $P/m \le OPT$, and the single largest job $p_j \le OPT$ (any schedule must place job j somewhere, taking at least $p_j$ time there). The "exchange" insight is that at the exact moment job j was placed, no machine could have been idler than machine i, so every machine had already absorbed unavoidable work, not that two individual schedule decisions are swapped directly.

Deadline extension: on a single machine, preemptive EDF is optimal for feasibility (it schedules any instance that has a feasible schedule at all). Once you combine online arrival, multiple machines, AND hard deadlines, no algorithm achieves a constant competitive ratio in the worst case; production systems fall back to a fast per-machine EDF feasibility check (admission control) layered on top of the same least-loaded routing, rather than chasing a provably-optimal global schedule.

import itertools

def greedy_list_scheduling(processing_times, m):
    """Assign each task, in arrival order, to whichever of the m machines
    currently has the smallest total load."""
    loads = [0] * m
    for p in processing_times:
        i = min(range(m), key=lambda k: loads[k])
        loads[i] += p
    return max(loads), loads

def optimal_makespan_bruteforce(processing_times, m):
    """Brute-force optimal offline makespan (small n only)."""
    n = len(processing_times)
    best = float("inf")
    for assignment in itertools.product(range(m), repeat=n):
        loads = [0] * m
        for idx, machine in enumerate(assignment):
            loads[machine] += processing_times[idx]
        best = min(best, max(loads))
    return best

m = 3
processing_times = [1, 1, 1, 1, 1, 1, 3]  # m*(m-1) unit tasks, then one size-m task
greedy_makespan, loads = greedy_list_scheduling(processing_times, m)
opt = optimal_makespan_bruteforce(processing_times, m)
print(f"greedy loads: {loads}, makespan: {greedy_makespan}")
print(f"optimal makespan: {opt}")
print(f"ratio: {greedy_makespan / opt:.4f}, bound (2 - 1/m): {2 - 1/m:.4f}")

Output:

greedy loads: [5, 2, 2], makespan: 5
optimal makespan: 3
ratio: 1.6667, bound (2 - 1/m): 1.6667

Worked example

With m = 3 machines, six unit-size tasks arrive first, then one size-3 task. Greedy spreads the six units evenly (2 per machine), then the size-3 task lands on whichever machine is currently tied for least-loaded, giving loads [5, 2, 2] and a makespan of 5. The optimal offline schedule instead puts the size-3 task alone on one machine (load 3) and splits the six unit tasks 3-and-3 across the other two (loads 3, 3), for an optimal makespan of 3. The ratio, 5/3 = 1.667, exactly matches $2 - \frac{1}{3}$: this is the standard tight instance showing the bound isn't just a proof artifact, an adversary really can force it.

Trade-offs & pitfalls

• The bound assumes identical machines with no migration; allowing tasks to migrate after the fact often does much better in practice, at the cost of moved-task overhead and more bookkeeping.
• The proof needs BOTH lower bounds ($P/m$ and $p_j$); relying on $P/m$ alone fails the moment one job is very large, since a single huge job forces a bigger optimal makespan than "average load" alone would suggest.
• Tie-breaking among equally-loaded machines does not affect the worst-case ratio, but a naive deterministic tie-break (always lowest index) can create structural correlation with adversarial arrival patterns; some implementations break ties randomly to avoid that.
• If tasks carry deadlines, "least-loaded" optimizes makespan, not deadline feasibility; the least-loaded machine at arrival time is not necessarily the one where this specific task's deadline is still reachable, so admission control needs its own per-machine feasibility check rather than trusting the load-balancing rule alone.
• The (2 - 1/m) bound does NOT generalize to machines with different speeds (unrelated or uniform machines): "current load" stops being the right proxy for "expected finish time" once machines process work at different rates, and a different assignment rule is needed.

Direct answer

With a stated 60% cacheable traffic share, fronting the API with a CDN (content delivery network, a globally distributed network of cache servers close to users) nets a few hundred dollars a month in savings on this workload once the CDN's own bandwidth and per-request fees are subtracted from the origin egress it avoids, and stays profitable down to a cacheable share far below 60% under the assumptions below, giving the recommendation real margin.

Structured elaboration

Illustrative unit rates used, not any specific vendor's real published pricing, always check current price lists before quoting a real number: origin egress $0.08/GB, CDN edge egress $0.04/GB, typically cheaper than origin at volume, and a CDN per-request fee of $0.0075 per 10,000 requests.

Approach: compute total requests and the bytes they imply from the given request-rate numbers, check whether that reconciles against the stated origin-egress figure, split bytes into cacheable and non-cacheable using the given 60%, price each segment at its own rate, add the CDN's per-request fee across all requests, hit or miss, since every request still touches the CDN, and compare total cost before versus after.

Worked example

Traffic: 2,000,000 requests/day x 30 days/month = 60,000,000 requests/month.

Implied bytes from the request-rate math: 60,000,000 x 100 KB = 6,000,000,000 KB, about 5,722 GB, roughly 5.6 TB/month. This does not match the stated 20 TB/month origin-egress figure, worth flagging as a real reconciliation gap to chase down before shipping a savings number externally, most likely other endpoints or traffic also hit this same origin. The stated 20 TB/month is used below as the billing baseline, since that is what the actual bill shows, not the request-rate estimate.

Origin bytes saved: 60% of 20 TB, 12,288 GB/month, moves to the edge; the remaining 40%, 8,192 GB/month, is non-cacheable and still originates from the backend even with a CDN in front.

Solving for the cacheable fraction that would make the before and after costs equal, under these same rates, gives a break-even around 5.5%, well below the stated 60%, so the CDN clears break-even with wide margin under these assumptions.

Trade-offs and pitfalls

All of this rests on the assumed unit rates and the 60% cacheable figure being close to reality; a real analysis pulls current vendor pricing and a measured cache-hit rate from the CDN's own reporting after a pilot, not before committing to a number. The math above ignores the one-time origin "fill" cost, the origin serving each object the first time it is requested at a given edge location, and treats ongoing cache maintenance as free; for content with a very short TTL (time-to-live, how long a cached copy is considered valid before being re-fetched) or a huge catalog with a low repeat-request rate, fills can matter and deserve their own line item. The stated 20 TB and the request-based 5.6 TB do not reconcile; shipping a savings number to a decision-maker without noting, and later resolving, that gap risks presenting a confident number built on an unverified baseline. Non-cacheable traffic, 40% here, gets no benefit from the CDN in this model and could even see a small latency add from a guaranteed-miss extra hop; worth checking whether to bypass the CDN entirely for known non-cacheable routes.

Why 1000 individual GETs is slow

Each GET is a full network round trip: send the command, wait for Redis to process it, wait for the response, before the next one can start (unless you're pipelining, batching multiple commands onto the wire together and reading all the responses back afterward, without waiting on each one individually, which is what the r.pipeline(transaction=False) call below does when loading the test data). At even a modest 0.5ms round trip, 1000 sequential calls is 500ms of pure network waiting, independent of how fast Redis itself is at looking the key up.

A faster approach: batch the request

Send all 1000 keys as a single command instead of 1000 separate ones, using MGET, which returns a list of values in the same order as the keys you asked for (with None/nil for any key that doesn't exist).

import time
import redis

r = redis.Redis(host="127.0.0.1", port=6399, decode_responses=True)

keys = [f"product:{i}" for i in range(1000)]
pipe = r.pipeline(transaction=False)
for i, k in enumerate(keys):
    pipe.set(k, f"value-{i}")
pipe.execute()

# Slow way: one GET per key = 1000 network round trips.
start = time.perf_counter()
slow_results = [r.get(k) for k in keys]
slow_elapsed = time.perf_counter() - start

# Fast way: MGET sends all 1000 keys in a single request/response round trip.
start = time.perf_counter()
fast_results = r.mget(keys)
fast_elapsed = time.perf_counter() - start

print("results match:", slow_results == fast_results)
print(f"1000x GET:  {slow_elapsed * 1000:.1f} ms")
print(f"1x MGET:    {fast_elapsed * 1000:.1f} ms")
print(f"speedup:    {slow_elapsed / fast_elapsed:.1f}x")

Output (measured on a local Redis instance; exact numbers vary by machine and network, but the shape holds):

results match: True
1000x GET:  638.5 ms
1x MGET:    1.6 ms
speedup:    390.2x

Why it's faster

MGET collapses 1000 round trips into one: the client sends every key in a single request, and Redis returns every value in a single response. The per-call network latency, which dominated the slow version, is paid exactly once instead of a thousand times.

What could still go wrong at that batch size

• In Redis Cluster mode, keys can be spread across different nodes by hash slot. A single MGET across keys that don't share a hash slot will fail (a CROSSSLOT error); you'd need to group keys by slot first, or use a hash tag (like {user123}.name, {user123}.email) to force related keys onto the same slot.
• Redis processes most commands on a single thread; a very large MGET (or a much bigger batch than 1000) can briefly block other clients while it's being served, so there's a point past which batching further hurts overall latency for everyone else rather than helping.
• If any of the 1000 keys are missing, MGET returns None in that position rather than raising an error, the caller must check for that positionally instead of assuming every key resolved.
• A very large response (1000 large values) can be a meaningful chunk of memory and bandwidth in one shot; if values are large, batching in smaller chunks (say 100 at a time) trades off round trips against peak response size.

Direct answer
Retry a callable up to max_attempts times, sleeping a randomized (full-jitter) delay between attempts that grows exponentially with each failure up to a cap, and re-raise the final exception unchanged if every attempt fails, so a caller can distinguish 'gave up after retrying' from any other failure mode.

Structured elaboration

• Exponential growth with a cap: delay = min(max_delay, base_delay * 2**(attempt-1)) grows the WAIT window each time, but never past max_delay, so a long-running outage doesn't produce absurdly long waits between attempts.
• Full jitter: sample the actual sleep uniformly from [0, delay] rather than sleeping the full computed delay every time; this is what actually de-correlates many clients that failed at the same moment (see the companion resilient-client-design survivor for why this matters at fleet scale).
• Preserving the last exception: on the final failed attempt, re-raise (don't swallow or replace) so the caller sees the real underlying error, not a generic 'retries exhausted' message that hides what actually went wrong.

Worked example (executed with a fake, non-real-time sleep injected for testability, per the reproducibility rule against wall-clock timing claims in tests; all assertions passed)

def retry(func, max_attempts=5, base_delay=0.1, max_delay=10.0, sleep=time.sleep):
    attempt = 0
    while True:
        attempt += 1
        try:
            return func()
        except Exception:
            if attempt >= max_attempts:
                raise
            delay = min(max_delay, base_delay * (2 ** (attempt - 1)))
            sleep(random.uniform(0, delay))

Verified: a function that fails twice then succeeds is called exactly 3 times and returns the success value, with 2 recorded sleep calls whose durations fall within the expected full-jitter bounds (first delay's upper bound base_delay, second's 2*base_delay); a function that always fails raises the original RuntimeError after exactly max_attempts calls, not a wrapped or generic exception.

Trade-offs and pitfalls
This implementation retries on ANY Exception, which is convenient to demonstrate but dangerous as shipped: it will happily retry a non-idempotent operation, and it will retry an exception type that indicates a permanent failure (a 400 Bad Request wrapped as an HTTP exception) exactly as eagerly as a genuinely transient one (a connection timeout); a production version should accept an explicit tuple of retryable exception types, exactly as the companion retry_with_backoff(exceptions=(...)) decorator-shaped survivors do, rather than defaulting to catching everything.