Netflix Backend Developer (Mid-Level) Interview Preparation Guide

Direct answer. Capture a baseline under realistic, steady-state conditions; run enough warm-up iterations to remove cold-cache noise, and enough repeated measurements to distinguish a real improvement from run-to-run variance; then compare the SAME set of metrics (not just wall-clock time) before and after, under matching concurrency, before calling the result statistically meaningful.

Structured elaboration. A fair baseline needs to reflect the workload's actual steady-state cache behavior, not an artificially cold cache (first run after a restart) or an artificially warm one (running the same query in a tight loop with nothing else happening), since either extreme can make a change look better or worse than it would in production. Run a handful of warm-up iterations before recording anything, then take enough repeated measurements to compute a distribution (not a single number), since a single before/after pair can't distinguish "genuinely faster" from "happened to catch a quiet moment." Collect more than wall-clock time where possible, buffer/IO statistics, CPU time, and (for a rewrite specifically) the plan shape itself, since two runs with similar wall-clock time but very different plan shapes tell you something different than two runs with the same plan shape and different timing. Match concurrency between the before and after runs; testing a rewrite in isolation and comparing it to a baseline captured under real concurrent load (or vice versa) invalidates the comparison.

Worked example. For a proposed query rewrite, a reasonable protocol is: run the original ten times (after three untimed warm-up runs), run the rewrite ten times under the same conditions, and compare the DISTRIBUTIONS of both wall-clock time and a secondary metric like buffer reads, rather than comparing single best-case or single arbitrary runs against each other; if the rewrite's distribution is meaningfully and consistently better across secondary metrics too (not just occasionally faster by chance), that's much stronger evidence than one favorable timing.

Trade-offs and pitfalls. It's tempting to declare victory off a single favorable before/after pair, especially under time pressure; resist that, since a single pair can't distinguish signal from noise, and a change that looked good in one measurement but doesn't hold up under repeated, matched-condition testing is exactly the kind of false confidence that erodes trust in benchmarking as a practice going forward.

Direct answer: HyperLogLog estimates the number of distinct items (cardinality) in a stream using only $O(\log \log N)$ space (in practice, a small fixed number of bytes per register, with a few thousand registers total regardless of N) by exploiting the statistics of hash-value bit patterns: the position of the leftmost 1-bit in a hashed value's binary representation is, on average, a strong signal for how many distinct items have been hashed. Typical implementations achieve roughly 1-2% standard error using around 1.5 KB of memory, regardless of whether the true cardinality is a thousand or a billion.

Structured elaboration

• Hash each incoming item to a uniform pseudo-random bit string. Split the hash into two parts: the first few bits select one of $m$ "registers" (buckets), and the remaining bits are scanned for the position of the leftmost 1-bit (equivalently, count of leading zeros plus one).
• Each register keeps the MAXIMUM leftmost-1-bit-position seen among all items hashed to it. Intuitively, if you've seen many distinct items, it becomes likely that at least one had a rare "many leading zeros" pattern purely by chance - the maximum observed value across all items in a register is a (noisy) signal for how many distinct items contributed to it.
• Averaging (harmonic mean, specifically, to reduce the impact of outlier registers) across all $m$ registers and applying a bias-correction constant gives the cardinality estimate. More registers ($m$) means lower variance/error but more memory - the standard error scales as roughly $1.04/\sqrt{m}$.
• Merging: two HyperLogLog sketches computed on disjoint data partitions can be merged into a single sketch representing the UNION simply by taking the element-wise MAXIMUM of corresponding registers - no need to re-scan the original data, which is what makes HLL naturally suited to distributed/partitioned counting (compute a sketch per shard, merge cheaply).

Worked example

With $m = 2^{14} = 16{,}384$ registers (a common real-world choice, using 6 bits per register for roughly 12 KB total), the standard error is approximately $1.04/\sqrt{16384} \approx 0.81\%$. This means estimating a true cardinality of, say, 10 million distinct users typically lands within about +/-81,000 of the true value (one standard deviation) - using roughly 12 KB regardless of whether the true count were 10 thousand or 10 billion, versus an exact count needing memory proportional to the actual distinct-item count (potentially many gigabytes for billions of distinct hashed identifiers).

Trade-offs & pitfalls

• HyperLogLog answers ONLY "how many distinct items" - it cannot tell you WHICH items were seen, unlike an exact hash set; if you need membership testing too, you need a different or additional structure (like a Bloom filter alongside it).
• Choosing $m$ is a direct accuracy/memory trade - doubling registers roughly halves standard error (since error scales as $1/\sqrt{m}$), but the memory cost is linear in $m$, so gains diminish (in a "cost per percentage point of accuracy" sense) as $m$ grows.
• The mergeability property is a major operational advantage over exact counting in a partitioned/distributed system, but the merge must be over sketches using the SAME hash function and register count - merging HLL sketches built with different configurations silently produces a meaningless result.

Direct answer

Redis is valuable for caching architecture beyond a plain key-value store because of its rich data types, native expirations, flexible eviction policies, clustering, replication, persistence options, and atomic scripting, each of which lets application logic that would otherwise need to live in your service move into the cache layer itself.

Structured elaboration

• Data types: beyond simple strings, Redis supports hashes (partial-object updates without rewriting a whole serialized blob), sorted sets (efficient ranking/leaderboard operations), sets (efficient membership checks and set operations), and lists, each mapping naturally to a specific caching use case rather than forcing everything into a generic key-value shape.
• Expirations: native per-key time-to-live (TTL) support means the cache itself handles expiry, rather than the application needing to check and manually evict stale entries.
• Eviction policies: configurable policies (allkeys-lru, allkeys-lfu, volatile-ttl, and others) let you tune eviction behavior to the workload's actual access pattern rather than being stuck with one fixed strategy.
• Clustering and sharding: Redis Cluster distributes data across many nodes with built-in hash-slot-based partitioning, giving horizontal scale without needing to build sharding logic in the application.
• Replication: built-in primary-replica replication (and Sentinel-managed automated failover) gives high availability without external tooling.
• Persistence modes: RDB (snapshotting) and append-only file (AOF, a write log) let a cache survive a restart, which matters for use cases where a full cold cache after every restart is unacceptable (session stores, for example).
• Lua scripting for atomic operations: a Lua script executes atomically (no other command interleaves mid-script), which is what makes safe multi-key or check-then-act operations possible without an external distributed lock.

Worked example

A leaderboard feature uses Redis sorted sets (ZADD to update a score, ZRANGE/ZREVRANGE to fetch a ranked slice) instead of storing scores as plain key-value pairs and computing rank in application code on every read; this pushes the O(log N) ranking operation into Redis itself, which is purpose-built for it, rather than requiring the application to fetch and sort a large dataset on every request.

Trade-offs and pitfalls

Reaching for Redis's richer features when a workload is genuinely simple key-value adds architectural surface area (more feature-specific operational knowledge required) without benefit; match the features actually used to the actual requirement. Persistence and replication address different failure modes (process restart versus node/disk loss); understand which specific risk each feature protects against before assuming either one alone is "enough" durability for a given use case.

Direct answer

Write amplification is the ratio of bytes physically written to storage to bytes the application logically asked to write; read amplification is the ratio of bytes, or I/O operations, the engine actually reads to satisfy one logical read. Both storage-engine designs, B-tree and log-structured merge-tree (LSM-tree, a design that buffers writes in memory and flushes them as immutable sorted files that get merged, or compacted, together in the background instead of updating in place), pay one of these costs more than the other by design: a B-tree trades higher write amplification for lower read amplification, an LSM-tree trades the reverse.

Structured elaboration

• B-tree write amplification: an in-place update to one row still requires rewriting the whole disk page (commonly 4 to 16 KB) that row lives on, and if that page has not been touched since the last checkpoint, a durability mechanism like write-ahead logging (WAL, the append-only log of changes an engine writes before applying them) may also log a full copy of that page before the change, adding to the physical write for that one logical row change. B-tree read amplification is low: a point lookup costs roughly one I/O per level of the tree, 2 to 4 for realistic table sizes, because there is exactly one place a given key can live.
• LSM-tree write amplification: writes go to an in-memory buffer (the memtable) and get flushed sequentially, so the initial write is cheap, but background compaction later rewrites the same data multiple times as it merges smaller sorted files into larger ones; a commonly cited rule of thumb, and it matches what RocksDB's own documentation says (leveled compaction write amplification is "often larger than 10"), is that data written once can be physically rewritten on the order of 10 to 60 times over its lifetime in a leveled LSM-tree, depending on the level size ratio and level count. LSM-tree read amplification is the mirror image: a point lookup for a key not in the memtable may have to check multiple sorted files across multiple levels before finding, or ruling out, the key, because the same key range can appear in several files at once.
• How to measure amplification operationally, not just estimate it: write amplification is measurable as physical bytes written to the storage device (from operating-system or device I/O counters) divided by logical bytes the application wrote (from the database's own row or byte write counters over the same window). Most LSM-based engines expose the compaction side of this directly: RocksDB's own statistics report bytes written by compaction versus bytes written by memtable flush, and Postgres exposes checkpoint and background-writer byte counts (pg_stat_bgwriter) that let you separate bytes caused by the logical write from bytes caused by checkpointing and full-page images. Read amplification is measurable as actual disk reads, or buffer-pool misses, per logical query; Postgres's EXPLAIN (ANALYZE, BUFFERS) reports it per statement, and RocksDB exposes similar per-lookup file-touched counters.
• Why it matters operationally, beyond a number to quote: high write amplification directly shortens solid-state-drive (SSD) lifespan, because flash storage wears out per physical write-erase cycle, not per logical write, and it directly consumes I/O throughput (the volume of data a disk can read or write per second) budget that could otherwise serve queries. A team seeing 30x write amplification on a write-heavy LSM-backed service is looking at a device that will hit its rated write-endurance limit roughly 30 times sooner than the application's logical write volume alone would suggest, and at background compaction I/O that competes with foreground reads and writes for the same disk bandwidth. That is a legitimate input into both a hardware over-provisioning budget and a decision to retune compaction, or pick a different storage engine, rather than an academic detail.

Worked example

Take a single-row update, roughly 30 bytes logically changed, on an 8 KB page (Postgres's default page size). In the B-tree case, that one 30-byte logical change can force an 8,192-byte page rewrite, an amplification factor of about 8192 divided by 30, roughly 273x, if it is the first change to that page since the last checkpoint and full-page-write protection is active. This is not a worst case invented for this answer: a live Postgres 16 instance measured exactly this shape, a single small-row insert advancing the write-ahead log by 7,800 bytes. In the LSM-tree case, that same 30-byte logical write is cheap on the way in (appended sequentially, no page rewrite), but if the engine is running standard leveled compaction with a level size ratio of 10 across 6 levels, a commonly used first-principles estimate for total lifetime write amplification is size ratio times levels, 10 times 6 equals 60x, because each level's compaction rewrites roughly the size ratio's worth of target-level data for every unit of source data merged in.

Trade-offs and pitfalls

The pitfall is picking a number off a blog post instead of measuring it on your own workload: amplification depends heavily on key distribution (monotonically increasing insert keys mostly extend a B-tree's rightmost edge with far fewer page rewrites than uniformly random insert keys scattered across the whole key space) and on tuning (a smaller level size ratio in an LSM-tree lowers write amplification but raises read amplification, since more levels means more places a key could be). The second pitfall is only counting the write path: read amplification matters just as much for latency-sensitive point lookups, which is exactly the gap Bloom filters (compact probabilistic structures that can quickly say "definitely not in this file," letting a lookup skip files it does not need to open) exist to close on the LSM side.

Direct answer

Latency and throughput are not opposites by nature, they trade off through queueing: pushing more concurrent work through a fixed amount of processing capacity increases the time each request waits behind others, and holding latency low means keeping spare capacity in reserve rather than running it flat out. The right balance comes from setting an explicit target for both (a throughput floor and a tail-latency ceiling), then using queueing math plus load testing to find the utilization level where more throughput starts costing more latency than the business can absorb. What to measure at each load level: the full latency distribution, not just the average, including the 95th and 99th percentile (P95/P99), alongside the downstream business metric (conversion rate, task completion time) the latency target exists to protect.

Structured elaboration

Why the tension exists. Little's Law ties the three quantities together:

$L = \lambda W$

where $L$ is the average number of requests in the system (concurrency), $\lambda$ is the arrival rate (throughput), and $W$ is the average time a request spends in the system (latency). For a fixed amount of concurrency capacity $L$, pushing $\lambda$ up forces $W$ up. Throughput and latency are linked by whatever capacity sits between them, they only look independent at low load.

Decision criteria to walk through, in order:

• Is there a hard external constraint (a contractual service-level agreement, or SLA) versus a soft internal preference? Hard constraints bound the feasible region before you optimize anything.
• Is the load steady or bursty? A bursty workload needs headroom sized for the peak, not the average, or tail latency spikes during every burst.
• What is the true cost of extra capacity relative to the revenue or reliability cost of extra latency? If compute is cheap relative to the business impact of latency, buy headroom instead of accepting queueing.
• Which metric does the product actually care about, median latency almost never predicts user-visible pain, the tail does.

Process: baseline the current latency distribution and throughput, ramp load in steps while recording the full distribution at each step, locate the point where the P95 or P99 curve bends upward sharply (the "knee"), then correlate that knee to the business metric to decide whether operating past it is acceptable.

Worked example

Assume, for illustration, a single worker with an average service time of 10 ms per request ($S = 0.01\text{s}$), so its theoretical maximum throughput is $1/S = 100$ requests per second (RPS). Using the M/M/1 queueing approximation (a standard model for one server handling one request at a time, with randomly arriving requests and randomly varying service times, a common simplification for a single queue), the average wait time in queue at utilization $\rho = \lambda S$ is:

$W_q = \frac{\rho \cdot S}{1-\rho}$

Reproducing the middle row: $W_q = \dfrac{0.90 \times 0.01}{1-0.90} = \dfrac{0.009}{0.10} = 0.09\text{s} = 90\text{ms}$, so $W = 90 + 10 = 100\text{ms}$. Going from 70 to 90 RPS (a 29% throughput increase) roughly triples latency; the next 5.6% of throughput (90 to 95 RPS) roughly doubles it again. This is the shape of the trade-off: throughput gains near saturation cost latency disproportionately.

The same law sizes capacity to hit both targets at once. To sustain 5,000 RPS at an average latency target of 15 ms, the required in-flight concurrency is $L = \lambda W = 5000 \times 0.015 = 75$ concurrent request slots. If each server instance can hold 25 concurrent requests (its thread or connection budget), raw sizing needs $75 / 25 = 3$ instances, but running at 100% utilization guarantees queueing, so target roughly 65% utilization for headroom: $3 / 0.65 \approx 4.6$, round up to 5 instances.

Trade-offs & pitfalls

• Treating the median as the target metric hides exactly the users experiencing queueing delay, always instrument and alert on the tail, not the average.
• Adding raw compute capacity fixes queueing-induced latency but does nothing for latency caused by serialization cost or an inefficient algorithm, these are different bottleneck classes and need different fixes (see bottleneck-identification questions for the diagnostic process).
• Batching or coalescing requests can raise both average throughput and average latency-per-request while making the tail worse for whichever request lands first in a batch, batching trades individual completion time for aggregate efficiency and needs a separate tail-latency check.
• Autoscaling on CPU utilization alone can under-react to a pure queueing problem, alerting or scaling on the latency percentile itself, or on queue depth, catches the tension directly.
• Always tie the chosen operating point back to the business metric with real data (an A/B test or canary), a default like "P95 under 300 ms" is only correct if it is where the business metric actually degrades.

Direct answer

Busier shows up in hours worked and volume of output; better shows up in what I can now do that I couldn't a year ago, or the same thing done with meaningfully less support, time, or error. So the evidence I look for is about capability, not throughput, and I check it against a target I set at the start of the period, not just once at year-end.

Structured elaboration

• Separate volume from capability directly. Shipping more of the same kind of thing at the same difficulty is throughput, not growth. The real signal is a new kind of problem you can now handle, or an old one you can now handle faster, more independently, or with fewer mistakes.
• Mix countable signals with qualitative ones. Countable: time to complete a class of task, error or rework rate, how far up an escalation chain you can now handle without help. Qualitative: what kind of problem people now bring you first, what you no longer need to ask about that you used to.
• Set the target ahead of time and reassess on a cadence. I pick one to three specific capability targets at the start of the period and check progress partway through, rather than only asking the question for the first time at the annual review, so the year-end check is a confirmation, not a surprise.
• Make the evidence legible outside your own team. I translate it into plain terms someone without your team's internal jargon could understand, since the whole point of evidence is that it should be checkable by someone who wasn't there for the year.

Worked example

Looking back over a year, I could point to a genuinely higher volume of deals worked, but that alone wouldn't have told me much. What I actually used as evidence was that at the start of the year, I could not scope and answer a technical objection from a prospect without pulling in a senior colleague, and by year end I could handle the majority of those unaided, with the colleague only looped in for a small, specific category I'd deliberately flagged as still outside my depth. I'd set that as an explicit target back in the first quarter, checked in on it at the midpoint by tracking how often I still needed to escalate a technical question, saw the rate dropping, and by year-end had a concrete number to show: escalations for that category had gone from roughly half of relevant conversations to under a fifth. That was legible to someone outside my team too, since it didn't depend on knowing our internal process, just on understanding what "needed help" versus "didn't" meant.

Trade-offs and pitfalls

The most common mistake is citing volume metrics like tickets closed or hours logged as if they were proof of growth, when they mostly measure how busy you were, not what you're now capable of. The opposite mistake is a vague self-assessment with nothing checkable behind it, which doesn't hold up when someone outside the situation asks for evidence. Judging growth only once, at year-end, is also risky, since it means you find out too late if the year didn't actually build the capability you assumed it would.

Direct answer

A disaster recovery runbook is only useful if a stressed engineer can execute it top to bottom without needing to look anything else up. That means naming an owner, stating the RTO and RPO it is designed to meet, listing ordered and specific actions (exact commands or console steps, not descriptions), and ending with concrete verification steps that prove the system is actually back, not just that the steps were followed.

Structured elaboration

Versioning and access. Store the runbook in source control with required review on changes, so every edit has an author and a diff. Test it in a real drill, not a tabletop discussion only, on a cadence tied to how critical the service is, quarterly for anything customer-facing. Keep it reachable when the primary systems it recovers are down: a runbook that lives only on an internal wiki hosted in the region that just failed is not a disaster recovery runbook.

Worked example

For a service with RTO = 30 minutes, a well-built runbook's step timings should sum to that budget, and the sum should be checked, not assumed:

$$5 + 5 + 15 + 5 = 30 \text{ minutes}$$

That sum matching the stated RTO exactly is what makes the RTO a testable claim rather than a number pasted at the top of the document. If a quarterly drill shows execution consistently takes 20 minutes instead of 15, the runbook's RTO is wrong and needs to be corrected, not explained away.

Trade-offs & pitfalls

• A runbook with no owner drifts out of date the first time the architecture changes; ownership is not optional metadata.
• Testing via tabletop discussion only, never an actual drill, hides the gap between the steps sounding right and the steps working; most drift is caught only by execution.
• Over-specifying every command for a fast-moving system creates a maintenance burden that causes the runbook to be abandoned; balance specificity against how often the underlying commands change.
• Storing the only copy behind the same authentication system that depends on the region that just failed is a common, self-defeating mistake.

Direct answer

An adjacency list (each node keeps a list of just its neighbors) uses memory proportional to the actual number of edges, while an adjacency matrix (an n by n grid marking which pairs are connected) always uses memory proportional to $n^2$ regardless of how many edges actually exist. For a sparse graph (few edges relative to $n^2$ possible pairs), that difference is enormous, and for a million nodes with average degree 10, an adjacency list is the clear choice.

Structured elaboration

For a sparse graph, the adjacency list wins on both memory and neighbor iteration, and only loses on single-edge existence checks, which can be recovered by backing each node's neighbor list with a hash set. For a dense graph (edges close to the $n^2$ maximum), the matrix's $O(n^2)$ memory is no longer wasteful relative to the edge count, and its $O(1)$ edge check becomes the deciding advantage, especially for algorithms that repeatedly ask "are these two connected" (for example, computing transitive closure over a dense graph, where a matrix-based approach like Warshall's algorithm, which repeatedly asks whether routing through each candidate intermediate node connects a pair that was not connected before, is a natural fit).

Concrete pick for a million nodes, average degree 10: with $n = 1{,}000{,}000$,

$$\begin{aligned} \text{adjacency matrix (1 bit/cell)} &: n^2 \text{ bits} = (10^6)^2 = 10^{12} \text{ bits} \\ &= \frac{10^{12}}{8} \text{ bytes} = 1.25 \times 10^{11} \text{ bytes} \approx 125 \text{ GB} \\ \text{adjacency list (8 B/reference)} &: n \cdot \bar{d} \cdot 8 \text{ bytes} = 10^6 \cdot 10 \cdot 8 \\ &= 8 \times 10^7 \text{ bytes} = 80 \text{ MB} \end{aligned}$$

Even at the most compact possible matrix encoding (a single bit per cell), the matrix needs about 125 GB, roughly 1,500 times more memory than the adjacency list's roughly 80 MB (assuming a compact, array-backed reference; a naive list of language-level objects would use more, but still nowhere near the matrix's footprint). The matrix is not just slower here, it is not a realistic option at all, so the adjacency list is the only workable choice.

Trade-offs & pitfalls

The most common mistake is defaulting to whichever representation is more familiar without checking density first; for the vast majority of real graphs (social graphs, web links, road networks, dependency graphs), average degree is a small constant or grows slowly with $n$, making them sparse, so adjacency lists dominate in practice. A second pitfall is assuming adjacency-list edge checks are always slow: if a node's degree is large, backing its neighbor list with a hash set restores $O(1)$ average edge checks without paying the matrix's $O(n^2)$ memory cost, which is usually the better middle ground than switching representations entirely. Converting between the two representations costs $O(n + m)$ to build a matrix from a list (visit each edge once) but $O(n^2)$ to build a list from a matrix (every cell must be scanned even if empty), which is itself a hint about which representation is cheaper to maintain as a sparse graph changes over time.

Direct answer
Signs pointing toward a security incident rather than a purely operational one include unexplained privilege or permission changes, authentication failures or account lockouts clustering in an unusual pattern, traffic or data-access patterns that look like exfiltration rather than normal load, and any sign of unauthorized file or configuration changes that nobody on the team made. Once you suspect any of these, the biggest change is that you stop trying to 'just fix it': you preserve evidence instead of immediately remediating, and you loop in a security responder rather than continuing to triage it as a routine outage.

Structured elaboration

• Signals that lean operational: the timing correlates with a known deploy or infrastructure change, the failure pattern matches a resource exhaustion or a known dependency issue, and the behavior is explainable by something the team did on purpose.
• Signals that lean security: access or configuration changes nobody recognizes, authentication anomalies (a spike in failed logins, logins from unusual locations, tokens being used in ways that don't match normal patterns), data being read or moved in volumes or patterns that don't match normal usage, or any indicator resembling a known attack pattern (credential stuffing, privilege escalation, lateral movement).
• What changes once you suspect it. You stop applying your normal 'fix it fast' instincts on the affected system, because touching it (restarting a process, wiping a disk, rotating credentials without first documenting state) can destroy evidence a security investigation needs. You loop in whoever owns security response, and from that point the deep investigation, containment technique, and evidence-handling discipline live with that team rather than being improvised by whoever happened to be on call.
• Who to involve: the security on-call or incident response function, as early as suspicion arises, not after you've already tried to resolve it yourself.

Worked example
A service starts throwing errors and the on-call engineer initially assumes it's a bad deploy, since that's the most common cause. But checking recent deploys shows nothing changed, and instead they notice a spike in failed authentication attempts against an admin endpoint in the minutes before the errors started, followed by a permissions change on a service account that nobody on the team made. That combination (no correlated deploy, authentication anomaly, unexplained permission change) is the tell that this isn't a routine outage; the engineer stops attempting further remediation, preserves the current state (avoids restarting the affected service, which could wipe useful logs), and escalates to the security team rather than continuing to debug it as an availability problem.

Trade-offs and pitfalls
The main risk under pressure is dismissing security signals too quickly because restoring service feels more urgent, which can mean actively destroying evidence (restarting a compromised host, deleting suspicious files 'to clean up') before anyone with security expertise has looked at it. The opposite risk is over-escalating every anomaly as a security incident, which burns the security team's time and can create alert fatigue that makes real security incidents harder to distinguish from noise; the right calibration is a small, well-understood set of signals (like the ones above) rather than a vague sense that 'something feels off.'

Direct answer. Extract a shared abstraction when the duplicated logic represents ONE concept that should change in lockstep everywhere it appears; keep the duplication when the copies are only coincidentally similar today and are likely to diverge for good reasons later. The deciding question is 'if this changes, should ALL copies change together, or might they legitimately need to change independently?'

Criteria that argue FOR extracting

• Change frequency and correlation: if past changes to one copy were always followed by the same change to the others (check git history/co-change), that's evidence the copies are meant to represent one concept.
• Correctness risk: if the logic is subtle (auth checks, financial rounding, retry/backoff math), duplication means a bug fix has to be remembered and reapplied N times; a shared function fixes it once for everyone.
• Low expected divergence: the copies serve callers with genuinely the same requirements today and no roadmap reason to expect that to change.

Criteria that argue AGAINST extracting (keep the duplication)

• Different actors, coincidental similarity: two services owned by different teams that happen to validate emails the same way today, but where one team's requirements are likely to diverge (say, one needs to support a different set of locales) -- forcing a shared abstraction now creates a coordination cost every time either team needs to change their copy.
• Early/uncertain code: if you're not yet sure what the RIGHT abstraction is, a premature shared function can lock in the wrong boundary (the 'wrong abstraction' problem) which is often more expensive to unwind than living with duplication a while longer.
• Small, stable snippets: three lines of straightforward validation that rarely change carry little risk either way; the coordination and indirection cost of a shared library can outweigh the benefit.

A concrete example

Caching logic duplicated across three services: if all three implement the SAME cache-invalidation semantics for the SAME reason (a shared upstream data source), extract it -- a subtle invalidation bug fixed in one place should fix it everywhere. If each service actually has different staleness tolerances and eviction needs that only LOOK similar today, extracting one 'shared caching abstraction' will force awkward configuration flags to handle the differences, which is often worse than three small, purpose-built implementations.

Trade-offs and pitfalls

• The decision isn't permanent: revisit it if the copies start to diverge meaningfully (evidence you were right to keep them separate) or if a bug has now been fixed in two of three copies but forgotten in the third (evidence you should have extracted).
• A shared library introduces a release/versioning cost (see the API-versioning survivor) that duplication doesn't have -- factor that operational cost into the decision, not just the code-level elegance.
• Don't let 'DRY' become dogma; the Sandi Metz framing is useful here: duplication is far cheaper than the wrong abstraction, because duplication is easy to later consolidate, while a bad shared abstraction is often harder to safely split back apart once callers depend on its exact shape.