Netflix Backend Developer (Mid-Level) Interview Preparation Guide

I would use caching selectively, with different rules for each data type.

Cache strategy

• Listing metadata: good candidate for cache-aside because it changes relatively infrequently.
• Host profile: also cacheable, usually with a medium TTL.
• Availability summary: cache very cautiously, with a short TTL or event-based invalidation, because stale availability can cause incorrect booking decisions.

Key design
I would build cache keys from stable identifiers and versioning, for example listing ID plus a data version or locale. That helps avoid collisions and makes invalidation safer after edits.

Invalidation

• On listing edits or host profile updates, publish an update event and evict or rewrite the related cache entries.
• On booking or hold creation, invalidate availability immediately or update it atomically.
• For high-risk data, prefer short TTLs plus invalidation instead of long-lived caching.

What I would never cache blindly

• Final booking authorization state
• Inventory counts that must be exact for correctness
• Any response that decides whether a slot is still bookable

For booking flows, I would rather pay a small latency cost than serve stale availability and create double-booking risk. Caching should improve read performance, not weaken correctness.

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
A 32-bit signed integer stores cents in the range $-2^{31}$ to $2^{31}-1$, which is -21,474,836.48 dollars to 21,474,836.47 dollars. Any operation that can push a balance past either end (a large deposit, a batch of many small deposits, a currency conversion that multiplies by a rate) either silently wraps to a huge negative number (classic overflow) or throws, depending on the language and whether checked arithmetic is used; a payment system test plan has to enumerate every code path that can reach that boundary, not just the "add a huge number once" case.

Structured elaboration
$\text{INT32\_MAX} = 2^{31} - 1 = 2{,}147{,}483{,}647 \text{ cents} = \$21{,}474{,}836.47$
$\text{INT32\_MIN} = -2^{31} = -2{,}147{,}483{,}648 \text{ cents} = -\$21{,}474{,}836.48$

Overflow/underflow risk is different per operation type and needs its own test cases:

• Deposits: a single deposit that pushes a balance from just under INT32_MAX to over it; also a deposit whose OWN value exceeds INT32_MAX before it even touches the existing balance.
• Withdrawals: pushing a balance below INT32_MIN is the underflow analog; also verify a withdrawal larger than the current balance is rejected by business logic (insufficient funds) before it ever reaches the arithmetic, since a naive implementation might let the subtraction wrap instead of validating first.
• Transfers: a debit-then-credit pair where the credit side overflows the recipient's balance even though the debit side is well within range; transfers also introduce a NEW risk class (partial application: debit succeeds, credit overflows and fails, leaving money in neither account) that pure deposit/withdrawal tests do not cover.
• Currency conversions: multiplying by a floating-point exchange rate before rounding back to integer cents can overflow at a much smaller starting balance than same-currency operations, and rounding direction (round half up vs. banker's rounding) needs its own dedicated cases independent of the overflow question.
• Batch jobs: a batch that touches many accounts is not just "the single-transaction case run N times"; test that ONE account hitting overflow mid-batch does not corrupt or silently skip the other accounts in the same run, and that the batch's failure mode (abort all, skip and log, or partial-commit) matches the documented contract.
• Repeated operations: many small deposits that each individually look safe but cumulatively cross the boundary; this is the case most likely to be missed because no single transaction looks dangerous in isolation, and it directly tests whether overflow protection is checked before or after each addition rather than only at input validation time.

Worked example

Automating detection, acceptance criteria, and mitigation: automate detection with property-based tests that generate random sequences of deposits/withdrawals/transfers and assert an invariant (sum of all account balances is conserved across transfers, no balance ever exceeds INT32_MAX or goes below INT32_MIN) rather than hand-writing every combination; run this alongside targeted boundary cases like the table above, since property tests are good at finding surprising sequences but boundary cases are more reliable for the exact edge itself. Acceptance criteria for "safe": every arithmetic operation on a balance is either using a wider integer type (64-bit) internally with a final range check, or uses checked/saturating arithmetic that raises rather than wraps; there is no code path where an overflow can occur silently. Mitigation with engineers: migrate balance storage to 64-bit integers (removing the realistic risk entirely, since $2^{63}-1$ cents is far beyond any real account balance) or add explicit overflow-checked arithmetic at every mutation point if a schema migration isn't feasible short-term; monitor in production with an alert on any balance within, say, 1% of the 32-bit boundary, so a customer legitimately approaching the limit is caught before they hit it, not after.

Trade-offs and pitfalls
A common mistake is testing only the deposit case and assuming withdrawal/transfer/conversion "obviously" behave the same; they do not, because transfers add the partial-application risk and conversions add floating-point rounding on top of the integer-overflow risk. Another mistake is testing overflow only as a single huge value, which misses the cumulative small-deposits case entirely, and that case is disproportionately likely to occur in real production data (a busy account with thousands of small transactions) compared to one dramatic deposit. Finally, silently wrapping on overflow (the C-style undefined/wraparound behavior in some 32-bit contexts) is categorically worse than throwing: a wrapped balance can go negative or reset near zero, and if that value is trusted downstream (e.g. displayed to the customer or used in a subsequent calculation) it becomes a real financial-integrity incident, not just a test failure.

Direct answer

An async image pipeline splits into three concerns: an ingestion API that only accepts the upload and durably records the job, a message queue that decouples ingestion from processing, and an autoscaled worker pool that performs the actual transforms and writes to storage behind a content delivery network (CDN). Idempotency, retries with a poison queue, and backpressure are what keep that pipeline correct and stable under bursty upload traffic, rather than just fast under ideal conditions.

Structured elaboration

Components. The ingestion API stores the raw upload directly to object storage and enqueues a small job message, a pointer or reference (the object key plus requested transforms), not the image bytes themselves, keeping messages small. An autoscaled worker pool consumes the queue, performs the transformations (resize, watermark), and writes the processed asset to a separate processed prefix or bucket, which the CDN serves from once available.

An alternative ingestion path skips the dedicated API entirely: the client uploads directly to object storage, and the storage service's own object-created event enqueues the processing job. This is the pattern a cost-driven batch-media pipeline leans on more heavily, and it works well here too for pure upload-then-process flows with no other request-time validation needed.

Failure handling. A worker's transform call can fail for many reasons: a corrupt upload, a transient storage read or write error, an out-of-memory condition on an unusually large image. On failure, the worker does not delete the message; it lets the message become visible again (or explicitly signals failure) so another attempt is retried, typically with a small number of retries and backoff. After the queue's own receive count exceeds a threshold, the message moves to a poison queue instead of being retried forever. This protects the healthy backlog from one malformed upload retrying endlessly and starving throughput for every other job behind it.

Idempotency. Because the queue and retries mean the same job can be processed more than once (a worker can crash after writing the processed asset but before acknowledging the message), the transform step is written to be safely repeatable. Deterministic output naming, a content hash or the same object key every time, not a freshly generated random name per attempt, means a second attempt overwrites the same output location rather than creating a duplicate asset. Pairing the write with a completion marker, checked at the start of the job, lets a redundant retry short-circuit once it sees the marker already present, instead of redoing expensive work.

Backpressure handling. The same producer/consumer backpressure principles apply here. The queue is bounded, and the ingestion path itself can apply admission control: if queue depth crosses a threshold, either shed new low-priority upload requests, or, more commonly for user uploads, keep accepting into object storage (cheap, durable, no processing needed yet) while only throttling how fast new processing jobs are admitted to the queue. Uploads are never lost even if processing lags.

Scaling workers for bursty traffic. Autoscale the worker pool on queue depth or the age of the oldest message rather than CPU utilization alone, CPU can look fine while a queue backs up if jobs are I/O-bound waiting on storage, with a fast scale-up policy and a slower scale-down to avoid flapping right as a burst subsides, plus a warm minimum worker count so a burst does not start from a fully cold pool.

Worked example

If a flash-sale-style event produces a burst of 10,000 uploads inside a 60-second window, and each worker processes roughly one image (resize plus watermark) per second as an illustrative per-worker throughput assumption, clearing that burst within the same window needs on the order of:

$$\text{peak workers} = \left\lceil \frac{10000}{60} \right\rceil = 167$$

A steady-state pool of, say, 10 to 15 workers plus an aggressive scale-up policy triggered by queue depth is what gets there without keeping 167 workers warm around the clock for a burst that happens only a few times a day.

Trade-offs and pitfalls

• Putting the image bytes themselves into the queue message instead of a storage reference inflates message size, wastes broker throughput, and often exceeds the broker's per-message size limit outright.
• Skipping the completion-marker check on idempotent writes means a retried job that already succeeded still redoes the (expensive) transform work even though the output would be identical, correct but wasteful.
• Autoscaling on CPU alone under-scales an I/O-bound pipeline exactly when it matters most, during a burst against slow object storage or network calls.
• No poison queue means one corrupt upload can occupy retry cycles indefinitely, or worse, crash-loop a worker repeatedly, degrading throughput for the entire backlog behind it.

Direct answer
For a global, latency-sensitive user-profile subsystem, a reasonable decomposition splits Profile Storage, Authentication, Preferences, and Avatar/Media Processing into separate services, each with a clearly different access pattern and failure-isolation need, communicating synchronously only where a request genuinely can't proceed without an immediate answer.

Structured elaboration
Authentication is kept separate because it's a security-sensitive, extremely high-frequency, low-latency dependency that nearly every other request needs to check, and isolating it means an issue in less-critical functionality (like avatar processing) can never take down the ability to authenticate a request. Profile Storage owns the core profile fields (name, settings, account state) and needs to be read on nearly every request, so it's optimized for fast, simple reads, kept narrowly scoped to just that core data rather than accumulating every profile-adjacent feature over time. Preferences (notification settings, UI preferences, and similar lower-stakes, less frequently-read data) is split out specifically because it doesn't need the same latency or availability guarantees as core profile and authentication data; if the Preferences service is slow or briefly unavailable, the rest of the profile experience should still work with sensible defaults, whereas Authentication being unavailable is a much more serious failure. Avatar/media processing is naturally asynchronous (resizing, transcoding, or moderating an uploaded image takes real time and doesn't need to block the rest of the profile experience) and has a very different resource profile (CPU/IO-heavy batch-style work) from the fast, simple reads the other services handle, making it a clear candidate for its own service with its own scaling behavior.

On communication choices: reading a user's core profile (needed on most page loads) should be synchronous, since the caller can't meaningfully proceed without it; updating a display avatar can be asynchronous, since the caller doesn't need to wait for image processing to finish, just for the upload to be accepted. Failure isolation follows from the split: if Avatar Processing is degraded, users can still authenticate, read their profile, and use the rest of the product, with a graceful fallback (a default avatar, or the previous one) rather than the whole profile experience failing.

Worked example
For team coordination across these services: the team owning Authentication needs the strictest change-management discipline given its security sensitivity and blast radius if it breaks, and its API contract with the other three services should be the most stable and carefully versioned of the four; Profile Storage's API needs to stay backward-compatible for the many other services and clients that read from it directly; Preferences and Avatar Processing, being lower-stakes and more independently used, can iterate faster with a lighter review process, as long as their optional, non-blocking nature is preserved (nothing else should come to depend on them synchronously in a way that would undo the isolation benefit).

Trade-offs and pitfalls
The most common mistake in a decomposition like this is letting Profile Storage's scope creep to absorb Preferences or other adjacent data over time ("it's just one more field"), which quietly recreates the coupling the split was meant to avoid; keeping the boundary honest requires treating a new field's home as a deliberate decision (does this need Profile Storage's stricter availability and latency guarantees, or can it live in the more relaxed Preferences service) rather than defaulting to wherever's most convenient to add it.

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

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

Shipping something isn't the finish line for me, it's the start of the actual test. My habit is to decide, before the change goes out, exactly which metrics I'll watch, how long I'll watch them, and what result would count as a real signal either way, so I'm not reasoning backward from whatever numbers happen to show up. Whatever the outcome turns out to be, it commits me to a specific next action rather than just quietly moving on.

Structured elaboration

Choosing metrics before shipping. I pick both a leading indicator, something that moves quickly and tells me early whether something's wrong, and a lagging one that reflects the actual outcome I care about. Deciding this beforehand matters because it's easy to convince yourself after the fact that whatever moved is the metric that mattered.

Setting the monitoring window. I decide how long to watch before I ship, not after, long enough to cover the natural cycle the metric runs on, a weekday-versus-weekend pattern, a billing cycle, a release cadence, so a good or bad number in the first day doesn't get over-read as the final answer.

Defining the signal in advance. I write down what result would count as "this worked" and what would count as "this didn't," before I see any data, specifically to avoid the trap of quietly reinterpreting an ambiguous result as good news after the fact.

Letting the result drive the next action. Once the window closes, the result isn't just filed away, it decides something concrete: keep the change as the new default, iterate on it, or roll it back. A monitoring effort that doesn't feed into an actual decision was never really monitoring, it was just watching.

Worked example

I once shipped a small toggle that raised a service's request-timeout threshold, after noticing the tight timeout was generating a lot of alerts that turned out to be false positives rather than real failures. Before shipping, I decided on three things to track: alert volume for that service, error rate, and p95 latency, since a wider timeout could theoretically mask a real problem instead of just tolerating slow-but-fine requests. I set the window at two weeks, long enough to cover multiple weekly traffic cycles rather than judging off a single quiet day. I defined success upfront as alert volume dropping meaningfully with error rate and latency staying essentially flat; if latency had crept up materially, that would have meant the wider timeout was masking a real backend problem rather than just tolerating noise.

After two weeks: alert volume for that service dropped from about 40 per week to about 6, an 85% reduction (34 divided by 40). Error rate was unchanged, and p95 latency moved from about 220 milliseconds to about 224, a change of under 2%, well within normal week-to-week noise. That combination, alerts down sharply with the health metrics essentially flat, was the signal that the alerts had genuinely been noise caused by too tight a timeout, not an early warning of something real. The result: I kept the new threshold as the permanent default, and as a follow-up, proposed replacing the static timeout-based alert with one keyed directly to latency, since that's closer to what we actually care about.

Trade-offs and pitfalls

Watching for too short a window is the most common mistake. A single good day after a Friday deploy can look great and just be a quiet weekend. Picking a metric that looks good on a dashboard but doesn't reflect the actual risk, tracking only alert volume here without also checking latency and error rate, would have missed a masked backend problem entirely. Not deciding the success criteria until after seeing the data invites reading whatever happened as a win. And watching the metrics without committing to a next action, letting a clearly negative result just sit there unaddressed, defeats the purpose of monitoring at all.

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.