Lyft Staff Site Reliability Engineer Interview Preparation Guide

Direct answer

Build this as a closed control loop, not a one-time placement decision: a stats collector measures per-partition access frequency and latency, a scoring engine turns those stats into a hot/warm/cold placement decision under an explicit cost budget, a migration executor carries out moves safely (copy first, flip a pointer, never move-then-copy), and a catalog-driven query router lets a single query transparently read partitions that are scattered across all three tiers by pruning to only the tiers and files it actually needs. An SLO (service-level objective: a measurable target for how the system should perform, such as a latency ceiling or a cost cap) monitor watches latency and cost against their targets and feeds back into the scorer, so the loop self-corrects instead of drifting.

Architecture

flowchart LR
  NVMe[(Hot: local NVMe)]
  SSD[(Warm: SSD cluster)]
  Obj[(Cold: object store)]
  Stats[Access and latency stats collector]
  Scorer[Tier scoring policy engine]
  Executor[Migration executor]
  Catalog[(Metadata catalog: partition to tier plus stats)]
  Router[Query router]
  SLO[SLO monitor and budget enforcer]

  NVMe --> Stats
  SSD --> Stats
  Obj --> Stats
  Stats --> Scorer
  SLO --> Scorer
  Scorer --> Executor
  Executor --> NVMe
  Executor --> SSD
  Executor --> Obj
  Executor --> Catalog
  Router --> Catalog
  Catalog --> Router
  Router --> NVMe
  Router --> SSD
  Router --> Obj

Every box is a real, separately deployable component: NVMe (the fastest commonly available local solid-state storage interface, hence the natural choice for the hot tier) sits as one edge of the loop, the object store as the other, and the catalog is the one piece every other component depends on, so it needs to be a small, highly available, always-hot store in its own right (a metadata service, not a file dropped in the object store), the same principle a Hive- or Glue-style metastore (a separate always-on service, used in big-data platforms, that tracks which files make up which table) or an open-table-format manifest such as Iceberg or Delta (a structured metadata file that plays the same role: a durable index of a table's data files) follows.

Tier-placement criteria and scoring

Score each partition on a blend of recency and frequency rather than either alone, since a partition read once an hour ago and a partition read a thousand times an hour ago are not equally "hot":

def tier_score(reads_last_24h, hours_since_last_read, recency_half_life_hours=6):
    recency_weight = 0.5 ** (hours_since_last_read / recency_half_life_hours)
    return reads_last_24h * recency_weight

# a partition read 200 times in the last day, but not touched in the last 3 hours
print(f"score: {tier_score(200, 3):.1f}")
# a partition read only 10 times, but 1 of those reads was 20 minutes ago
print(f"score: {tier_score(10, 0.33):.1f}")

Output:

score: 141.4
score: 9.6

Rank partitions by this score each cycle, promote the top scorers toward hot (subject to the budget check below) and demote the ones that have fallen furthest since the last cycle. The exact scoring formula matters less than the principle: base it on the same signal (access pattern) the SLOs are measured against, and re-evaluate it on a fixed cadence rather than only reactively.

Migration mechanics (why safety, not just correctness, is the hard part)

The failure mode to design against is a reader hitting a partition mid-move and getting either stale or missing data. The safe sequence:

1. Copy the partition's data to the destination tier. The source is untouched and still fully readable throughout.
2. Verify the copy (checksum comparison against the source).
3. Atomically update the catalog's tier pointer for that partition to the new location. This is the single moment the migration becomes visible to readers; it's a metadata write, not a data write, so it's fast and can be done as one transaction.
4. Only after the pointer flip is confirmed, delete the data from the source tier.
   Never move-then-copy (delete first, copy second): any failure between those two steps loses the data outright. Never expose a partial write of the copy at the destination: readers must only ever see either the old location (fully intact) or the new one (fully intact and verified), never a half-written destination.

Cross-tier query routing (the mechanism, not just the claim)

A query spans tiers by pruning at the catalog, not by asking every tier "do you have this." The catalog stores, per partition, its current tier plus the same partition statistics (min/max key ranges, row counts, column statistics) a query planner (the part of a database or query engine that decides how to execute a query) would use for predicate pushdown: skipping, that is pruning, whole files or partitions that the query's filter conditions cannot possibly match, using those stored stats, instead of reading every file to check. This is exactly the way a Hive- or Glue-style metastore or an Iceberg/Delta manifest does it today. The query router's job:

1. Take the query's predicates (a date range, a key range).
2. Look up the catalog to get the list of partitions that match those predicates, along with each matching partition's current tier.
3. Group the matching partitions by tier and dispatch a scan to each tier's own read path in parallel (NVMe local reads, SSD-cluster reads, object-store GET/scan requests).
4. Merge the results, exactly as a query engine already merges results from multiple files today; spanning tiers is the same fan-out-and-merge pattern, just with three different storage backends instead of one.
   This is why the catalog carrying partition statistics matters: without it, "transparently spans tiers" degrades into scanning every tier for every query, defeating the entire cost benefit of the cold tier being cheap because it's rarely touched.

Measuring and enforcing latency and cost SLOs

• Latency SLO: track p95/p99 read latency per tier (95th/99th percentile: the latency value that 95%/99% of reads finish faster than) against a target, e.g. "p99 for hot-tier reads under 5 ms." A tier whose p99 is breaching its target is a signal to the scorer to be more aggressive about keeping genuinely hot data on NVMe rather than a signal to add more NVMe capacity blindly; check whether the SLO breach is a placement problem (wrong data is hot) before treating it as a capacity problem.
• Cost SLO (budget enforcement): the scorer's promotion decisions are budget-checked, not just score-ranked. If promoting everything that scored above threshold would exceed the monthly budget, promote only the highest-scoring subset that fits within remaining headroom, and leave the rest queued for the next cycle:

total_tib, hot_frac, warm_frac = 20, 0.05, 0.25
hot_tib, warm_tib = total_tib*hot_frac, total_tib*warm_frac
cold_tib = total_tib*(1-hot_frac-warm_frac)

# Illustrative unit costs ($/TiB-month), not a live vendor quote
c_nvme, c_ssd, c_obj = 90, 25, 3
budget = 300

cost = hot_tib*c_nvme + warm_tib*c_ssd + cold_tib*c_obj
headroom = budget - cost
requested_promotion_tib = 1.0
marginal_cost_per_tib = c_nvme - c_obj
affordable_tib = headroom / marginal_cost_per_tib

print(f"current cost ${cost:.0f} of ${budget} budget, headroom ${headroom:.0f}")
print(f"scorer flags {requested_promotion_tib:.1f} TiB as hot-worthy; "
      f"budget only affords promoting {affordable_tib:.2f} TiB")

Output:

current cost $257 of $300 budget, headroom $43
scorer flags 1.0 TiB as hot-worthy; budget only affords promoting 0.49 TiB

The executor promotes the top-scoring 0.49 TiB and leaves the remaining 0.51 TiB queued rather than silently blowing the budget by promoting the full 1.0 TiB; the next cycle re-evaluates as older hot data ages out and frees headroom. This is the concrete difference between "measuring" an SLO (a dashboard number) and "enforcing" one (a decision the system actually makes because of that number).

Trade-offs and pitfalls

• A scoring cycle that runs too infrequently (say, once a day) means the system reacts to yesterday's access pattern, not today's; too frequently, and the migration churn itself (constant copying) eats the budget it's supposed to protect. Tune the cadence against how quickly your access patterns actually shift, not by habit.
• Budget-constrained promotion queues up demand that never gets served if the workload's hot working set has genuinely outgrown the NVMe budget; that's a signal to revisit the budget or the hot-tier sizing, not a problem the scorer can solve by prioritizing harder.
• Skipping the copy-verify-flip-delete sequence in favor of a faster move-in-place is exactly the shortcut that turns an ordinary migration into a data-loss incident the first time it's interrupted mid-move (a crash, a network partition).
• If the catalog and the query router live in different failure domains, a catalog update that succeeds but doesn't propagate to the router in time produces a stale read plan; treat catalog reads on the query path as needing to be current, not eventually consistent (a system that only promises all readers will see the same data EVENTUALLY, after some unspecified lag, rather than immediately), or the "transparently spans tiers" property silently breaks for a window after every migration.

Direct answer

Neither path is inherently better. The honest answer names what you're optimizing for right now, depth of leverage and marketability in a narrow area, versus flexibility and broader career options, and states plainly what you're giving up by choosing one, rather than pretending you can maximize both at once.

Structured elaboration

Define the trade-off in your own terms. Deep specialization trades breadth of future options for concentrated leverage and recognition in one area. Staying a broad generalist trades peak depth in any one area for flexibility, resilience to shifts in what your organization needs, and often a more natural path into roles that require breadth.

Name what you're consciously trading away, specifically. If you specialize, you accept slower or harder pivots later and reliance on organizations that value that specific depth. If you generalize, you accept giving up the strongest, most differentiated reputation in any single area, and possibly slower recognition in fast, depth-rewarding tracks.

Ground the choice in something real. Your current stage, early career often benefits from some depth to build a track record, later career often benefits from breadth for leadership options, what your organization or market currently rewards, and where your genuine interest sustains itself over time.

Apply a useful test. Describe a specific moment where you actually had to choose between a deep technical option and a broader, stakeholder-facing one, and what you picked. A real decision under real constraint tells an interviewer far more than a stated preference in the abstract.

Worked example

"At one point I had two real options in front of me at the same time, a deep technical project that would make me the clear expert in a narrow area few others touched, or a stakeholder-facing initiative that would put me in front of more of the organization with less technical depth involved. I chose the stakeholder-facing option, consciously, because at that stage I already had reasonable depth in my area and what I was missing was visibility and cross-functional experience, which the deep project wouldn't have given me regardless of how well I executed it. I was explicit with myself that I was trading a chance to become the clear go-to expert in that narrow area for broader relationships and exposure, and that someone else would likely become that expert instead. Looking back, the choice matched what that stage of my career actually needed, which is the test I'd apply again, not which option sounds more impressive, but which trade-off fits where I am now."

Trade-offs & pitfalls

• Treating this as a values statement, I love learning new things, without naming the actual cost of the choice reads as avoiding the harder half of the question.
• Claiming you can do both fully at once. Some blending is real, build depth then broaden, or vice versa, in phases, but pretending there's no trade-off undercuts your credibility.
• Answering based on what sounds better in an interview rather than what you'd actually choose usually shows in the lack of a concrete supporting example.
• A generalist claim with no depth anywhere reads as avoiding commitment, just as a specialist claim with no awareness of the narrowing risk reads as naive about the market.

Direct answer
An incident is unplanned degradation you did not choose the timing of, and it demands an immediate, ad hoc response. A change is planned work you scheduled, reviewed, and can roll back on your own terms. The core difference is control: with a change you set the clock and the safety net in advance; with an incident, both are decided under pressure, in real time.

Structured elaboration

• Response process. A change follows a pre-agreed plan (a rollout schedule, a rollback procedure written before you started). An incident has no such plan available; the responder is improvising against a runbook at best, from first principles at worst.
• Communication expectations. A change is usually announced in advance ('deploying at 2pm, expect brief latency') and confirmed complete afterward. An incident communication starts reactively ('we're aware of X, investigating') and needs a cadence of updates because nobody agreed to this timing.
• Approvals. A change typically needs sign-off before it happens (a peer review, a change-advisory step for higher-risk changes). An incident response needs no advance approval to act, since delay itself has a cost, though bigger interventions (a full rollback, a customer-facing statement) may still need someone with authority to say go.
• Post-activity documentation. A completed change gets a short record that it happened and worked as intended. An incident gets a fuller review, because the whole point is extracting a lasting lesson from something nobody planned for.

Worked example
A team schedules a canary rollout of a new caching layer for 2pm, reviewed and approved the day before, with an automatic rollback if error rate crosses a threshold. That's a change: planned, approved, monitored against a pre-set safety trigger. At 2:15pm the canary's error rate stays low but an unrelated dependency the caching layer talks to starts timing out, and the on-call engineer gets paged for a 5xx spike unrelated to the rollout. That's now an incident: nobody scheduled it, there's no pre-agreed plan for this specific failure, and the engineer has to improvise triage in real time, even though it happened to start during a change window.

Trade-offs and pitfalls
A common failure mode is applying incident-level ceremony to every change, which breeds change fatigue and makes people route around the process. The opposite failure is worse: not declaring an incident when a change goes wrong, often because the team feels responsible ('we did this to ourselves, let's just quietly fix it') and skips the visibility, communication, and review that an incident would otherwise get. A bad outcome caused by your own planned work is still an incident and deserves the same rigor as one caused by anything else.

Direct answer

Hundreds of ad-hoc Bash scripts migrating to a centralized platform is a genuinely large undertaking where the risk isn't any single migration step, it's the aggregate exposure of touching hundreds of production-adjacent scripts -- so the plan has to be sequenced by risk, not just by convenience.

Discovery and inventory

Before migrating anything, build a complete inventory: what scripts exist, where do they run (cron, manually, CI), what do they actually do, how often, and critically, HOW risky is each one if it breaks (does it touch production data, is it destructive, is it on a critical path). This inventory is the input to every subsequent decision -- migrating blind, without knowing what you actually have, is how a migration effort quietly misses a critical script nobody remembered existed until it broke.

Risk-based prioritization

Rank by the same frequency x impact x risk logic used elsewhere in this topic for toil prioritization, but inverted for migration ORDER: migrate LOW-risk, well-understood scripts FIRST (to build confidence in the platform and the migration process itself with low stakes), and save the highest-risk, most business-critical scripts for LAST, once the platform and the team's migration muscle-memory are both proven on lower-stakes work.

Refactoring strategy: bash into reusable modules

Don't do a literal line-for-line Bash-to-Python translation -- that just moves the same design (often lacking the idempotency/retry/logging discipline this topic argues for) into a new language without fixing anything. Instead, decompose each script into its actual PURPOSE (what desired state does it establish, what side effects does it have) and reimplement using the platform's shared primitives (retry, secrets, logging, CLI framework) rather than reinventing them per-script -- this is where the real value of centralizing comes from, not just 'the same logic in a different language.'

Testing, packaging, rollout, rollback

Each migrated script needs its OWN test coverage (unit + integration, per the testing discipline covered elsewhere in this topic) before being trusted to replace the Bash original -- run the new version in SHADOW mode alongside the still-active original for a validation period (comparing outputs/behavior) before cutting over, exactly the pattern recommended for migrating manual runbooks to automation elsewhere in this topic. Package and version each migrated script through the platform's standard packaging path, not ad-hoc. Roll out script-by-script (never migrate everything simultaneously), with an explicit, tested rollback path back to the original Bash script for each one, kept available until the new version has proven itself in production for a defined period.

Documentation, training, success metrics

Document the NEW version per the maintainability-checklist discipline covered elsewhere in this topic (owner, runbook, what it does) since a migrated script inherits none of the tribal knowledge that may have existed (however informally) around the original. Train the teams who'll actually operate these day-to-day, not just the migration team. Measure success concretely: number of scripts migrated (progress), incident rate for migrated vs not-yet-migrated scripts (does centralizing actually reduce operational risk, the core hypothesis being tested), and time saved per migrated script versus migration effort spent (is the ROI holding up as the effort progresses, or degrading on harder scripts).

Trade-offs and pitfalls

The most common failure mode in a migration this large is treating it as a fixed-scope project with a deadline rather than an ongoing, prioritized queue -- forcing a hard deadline on hundreds of scripts of wildly varying risk and complexity creates pressure to rush the highest-risk ones just to hit the date, which is exactly backwards from the risk-based sequencing this plan is built around.

Situation: During a partial production outage affecting user login, two senior engineers proposed different remediations—Engineer A recommended a conservative rollback to the last known-good deploy; Engineer B proposed a risky hotfix that could restore service faster but might introduce data inconsistencies.

Task: As the SRE leading the response, I needed to facilitate a rapid, safe decision, minimize user impact, and ensure we captured the decision rationale and learnings afterward.

Action:

• Rapid triage (minutes): I asked both engineers to state succinctly (1) expected time-to-recovery (TTR), (2) risk profile (blast radius, data safety), (3) rollback/hotfix steps and required approvals, and (4) monitoring/verification plan.
• Risk matrix on the fly: I mapped TTR vs. risk and checked current error budget and business urgency (was an SLO breach imminent?).
• Decide with guardrails: If hotfix TTR < rollback TTR by a clear margin and risks were containable (feature flags, DB transactions reversible), I authorized a staged hotfix in a canary region with automated rollback triggers. Otherwise I ordered the rollback.
• Communication: I broadcast the decision, expected timeline, verification steps, and contingency plan to stakeholders; assigned a runbook owner and an observer to monitor for regressions.
• Documentation: I captured the decision, evidence, trade-offs, and commands used in the incident ticket in real time so the timeline was auditable.

Result:

• We restored service within the projected TTR using the chosen path; automated verification caught a regression and triggered rollback, preventing data loss.
• Post-incident: I ran a blameless postmortem within 48 hours documenting root cause, decision rationale, what worked, and gaps (e.g., insufficient canary coverage). Action items included adding a pre-approved emergency hotfix checklist, improving canary tooling, and updating rollback automation. I assigned owners and tracked completion.

This approach balances speed and safety by forcing concise risk/benefit articulation, using measurable guardrails (SLOs, canaries, automated rollbacks), and ensuring decisions and learnings are documented and acted on.

Direct answer

Advance one pointer (slow) one step at a time and another (fast) two steps at a time. If the list has no cycle, fast reaches the end first and you can report there is none. If it does have a cycle, fast eventually laps slow and the two meet somewhere inside it. Once they meet, restarting one pointer at the head and advancing both pointers one step at a time makes them meet again exactly at the cycle's start. All of this uses $O(1)$ extra space, no visited set required.

Structured elaboration

Why meeting implies a cycle, and why no meeting implies no cycle. With no cycle, fast strictly gains ground toward a null terminator every step and reaches it in at most n/2 steps; it can never occupy the same node as slow without a cycle to loop back through. Once both pointers are inside a cycle, fast closes the gap to slow by exactly one node per step, because fast gains two steps of distance while slow gains one, a net closing rate of one per step. Since the gap can never exceed the cycle's length, they are guaranteed to meet within one full lap of the cycle.

Why the meeting point locates the cycle's start. Let a be the distance from the head to the cycle's start, c be the cycle's length, and b be the distance from the cycle's start to the meeting point, with $0 \le b < c$. By the time they meet, slow has traveled a + b steps and fast has traveled exactly twice that, but fast has also gone around the cycle some whole number of extra laps $n \ge 1$:

So a and (c - b) differ by a whole number of cycle lengths, meaning a pointer walking one step at a time from the head, and a pointer walking one step at a time from the meeting point, land on the same node after exactly a steps: the cycle's start.

Related applications of the same fast/slow pattern. Removing the n-th node from the end of a list uses the same shape without any cycle involved: advance one pointer n steps first, then move both pointers together; when the front pointer reaches the end, the trailing pointer sits exactly at the node to remove. Finding a duplicate number hidden in an array reframes the array itself as an implicit linked list, where the value stored at each index tells you which index to visit next; a repeated value forces two different positions to point at the same next index, creating a cycle in that implicit list, which Floyd's tortoise-and-hare detects exactly the way it detects a cycle here.

Worked example

class Node:
    def __init__(self, val, next=None):
        self.val = val
        self.next = next


def detect_cycle_start(head):
    slow = fast = head
    while fast and fast.next:
        slow = slow.next
        fast = fast.next.next
        if slow is fast:
            ptr = head
            while ptr is not slow:
                ptr = ptr.next
                slow = slow.next
            return ptr
    return None


if __name__ == "__main__":
    nodes = [Node(i) for i in range(5)]  # values 0,1,2,3,4
    for i in range(4):
        nodes[i].next = nodes[i + 1]
    nodes[4].next = nodes[2]  # cycle back into node with value 2
    start = detect_cycle_start(nodes[0])
    print(start.val)

Running this prints 2. In the derivation's terms: a = 2 (two steps from the head, value 0, to the cycle's start, value 2), c = 3 (the cycle 2 to 3 to 4 back to 2 has three edges), and the two pointers first meet at the node with value 3, so b = 1 (one step from the cycle's start to that meeting point). Checking the identity: c - b = 3 - 1 = 2, which equals a, confirming the derivation against this concrete run.

Complexity

Time: $O(n)$. The pointers meet within one full lap of the cycle once both are inside it, and finding the cycle's start afterward takes at most another full lap; both phases are bounded by a constant multiple of the list's length n.
Space: $O(1)$, since only the slow and fast pointers (and later ptr) are held, with no visited set.

Edge cases

• Empty list (head is None): fast is None immediately, so the loop never runs and the function correctly returns no cycle.
• Single node with no self-link: fast.next is None on the first check, so the loop exits immediately with no cycle detected.
• Single node that cycles to itself: slow and fast both land back on that same node on the first iteration, correctly reporting it as the cycle's start.

Trade-offs & pitfalls

A common bug is comparing pointer values instead of pointer identity; when list values can repeat, slow.val == fast.val can be true without slow and fast being the same node, so the check must be slow is fast.

Five 90-day metrics should be concrete, cheap to measure with data you already have or can get quickly, and tied to something the team actually cares about, not vanity numbers. I use the SMART framework (Specific, Measurable, Achievable, Relevant, Time-bound) as the filter for whether a proposed metric is real or just an aspiration. Below is the set I would commit to, each with why it matters, the data source and method, and a target range. The ranges are opening positions stated on the assumption of an average existing baseline; I would confirm or renegotiate each one in week two or three against the team's real numbers, and I say that out loud rather than pretending day-one precision I do not have.

1. Shipped, reviewed deliverables tied to the team's top objective. Why it matters: it proves I can navigate the codebase, the review culture, and the release process, which is the precondition for everything else. Source and method: count merged changes in version control, filtered to the objective's tracking label, excluding trivial changes. Target: at least two substantive changes merged by day 45 and six to eight by day 90, and every one of them reviewed by someone other than my onboarding buddy.

2. One validated impact result, with its unit cost. Why it matters: output that nobody can attribute is indistinguishable from busywork. Source and method: an A/B test (a controlled comparison against a held-out group that does not get the change) read from the experimentation platform, paired with the serving or query cost per unit pulled from the cloud billing export. Target: one experiment designed, shipped and read out inside 90 days, with the result reported honestly whether it won or lost, and unit cost held at or below the agreed ceiling rather than traded away for the win.

3. A reliability improvement on something a downstream consumer depends on. Why it matters: the pipeline or service running is not the point, the consumer trusting it is. Source and method: the scheduler or monitoring tool's run history for failure and late-delivery rate over a rolling 30 days, confirmed with the two or three teams that consume the output. Target: cut the failure-plus-late rate on one named dependency by roughly half against its trailing 30-day baseline, and get that confirmed by a consumer in their own words, not just on the dashboard.

4. Finished work with a quality bar attached. Why it matters: counting work in progress is how a quarter disappears with nothing landed. Source and method: the team's tracker, counting only items that reached production and carry a documented accuracy, adoption, or acceptance check. Source of the quality number is whatever the team already records; if it records nothing, establishing that record is itself part of the metric. Target: two to three finished items by day 90, none of them still labelled in review.

5. Adoption of one thing I built, by a named group. Why it matters: a dashboard or tool nobody opens is an output metric pretending to be an impact metric. Source and method: the tool's own usage log for weekly active viewers in the target group, plus a short qualitative check with three of those users on whether it changed a decision. Target: a majority of the named target group using it weekly by day 90, and at least one concrete decision someone can point to. I would avoid leaning on a Net Promoter Score here: it is a loyalty measure built from a single likelihood-to-recommend question scored zero to ten, it needs far more respondents than a ten-person stakeholder group to be stable, and weekly active use plus three honest conversations tells you more at this size.

How the same five slots look in different roles

The slots are deliberately generic because they travel. Slot 1 is a Software Engineer's "did specific, verifiable work land." Slot 2 is the AI Engineer flavor: impact plus inference cost per prediction, not accuracy alone. Slot 3 is the Data Engineer's consumer-benefit framing. Slot 4 is the Data Scientist's way of counting finished models or analyses rather than work in progress. Slot 5 is the BI Analyst's dashboard-adoption framing. A Solutions Architect's version blends slots 3 and 5: pick a specific customer or internal team consuming your architecture recommendations, and track whether that team actually adopted the recommended design, not just whether you delivered a document, confirmed directly with them.

Trade-offs and pitfalls

Committing to a hard numeric target before you have seen the team's real baseline is a common mistake, which is why every range above is explicitly an opening position to be reset in week two or three. The opposite mistake is worse in an interview: refusing to name any number at all reads as hedging, so state the range and state what would move it. A subtler pitfall is picking five metrics that are all about your own output (things you did) with none about downstream impact (things that changed because of what you did); slots 1 and 4 are output, slots 2, 3 and 5 are impact, and a strong set always has at least one of each.

Approach

An M/M/c queue models c identical servers, each serving at rate mu (requests/second per server), sharing one arrival stream at rate lambda. "M/M/c" means Markovian (memoryless, exponentially-distributed) arrivals, Markovian service times, and c servers. The Erlang C formula gives the probability an arriving request has to wait at all, and from that, the average wait time in queue.

a = lambda / mu                          (offered load, in erlangs)
C(c, a) = [ a^c / c! * c / (c - a) ] / [ sum_{k=0}^{c-1} a^k/k!  +  a^c/c! * c/(c - a) ]
Wq = C(c, a) / (c * mu - lambda)         (average wait time in queue)

Plain-English intuition: a is how many servers' worth of work is arriving on average. C(c, a) is the probability of queueing rather than being served immediately (the classic "Erlang C" blocking-probability formula from telephony). Wq divides that queueing probability by the system's spare service rate (c*mu - lambda), so as c approaches a, spare capacity shrinks toward zero and wait time blows up.

import math

def erlang_c_wait_prob(c, a):
    if a >= c:
        return 1.0  # unstable: arrivals outpace total service capacity
    sum_terms = sum((a ** k) / math.factorial(k) for k in range(c))
    last_term = (a ** c) / math.factorial(c) * (c / (c - a))
    return last_term / (sum_terms + last_term)

def mmc_avg_wait(lam, mu, c):
    a = lam / mu
    if a >= c:
        return float("inf"), 1.0, a
    C = erlang_c_wait_prob(c, a)
    Wq = C / (c * mu - lam)
    return Wq, C, a

def min_servers_for_target(lam, mu, target_wait_s):
    c = math.ceil(lam / mu) + 1  # c must exceed offered load to be stable
    while True:
        Wq, C, a = mmc_avg_wait(lam, mu, c)
        if Wq <= target_wait_s:
            return c, Wq, C, a
        c += 1


if __name__ == "__main__":
    print("Front-end service: lambda=1000 req/s, mu=50 req/s/server, target Wq<=100ms")
    c, Wq, C, a = min_servers_for_target(1000, 50, 0.100)
    print(f"  offered load a = {a:.2f} erlangs, minimum servers c = {c}")
    print(f"  utilization rho = a/c = {a/c:.3f}, P(wait>0) = {C:.4f}, Wq = {Wq*1000:.2f} ms")

    print("ML-inference service: lambda=200 req/s, mu=25 req/s/replica, target W<=15ms")
    c2, Wq2, C2, a2 = min_servers_for_target(200, 25, 0.015)
    print(f"  offered load a = {a2:.2f} erlangs, minimum replicas c = {c2}")
    print(f"  utilization rho = a/c = {a2/c2:.3f}, P(wait>0) = {C2:.4f}, Wq = {Wq2*1000:.2f} ms")

    Wq_below, C_below, _ = mmc_avg_wait(200, 25, c2 - 1)
    print(f"  at c={c2-1} (one below the minimum), Wq = {Wq_below*1000:.2f} ms, over the 15ms target")

Output:

Front-end service: lambda=1000 req/s, mu=50 req/s/server, target Wq<=100ms
  offered load a = 20.00 erlangs, minimum servers c = 21
  utilization rho = a/c = 0.952, P(wait>0) = 0.7606, Wq = 15.21 ms
ML-inference service: lambda=200 req/s, mu=25 req/s/replica, target W<=15ms
  offered load a = 8.00 erlangs, minimum replicas c = 10
  utilization rho = a/c = 0.800, P(wait>0) = 0.4092, Wq = 8.18 ms
  at c=9 (one below the minimum), Wq = 26.13 ms, over the 15ms target

Key results and what they mean

Front-end service: the offered load is 20 erlangs (1000/50), so the absolute floor for stability is 21 servers (any fewer and the queue grows without bound). At exactly that floor, the wait comes out to about 15 ms, comfortably under the 100 ms target. In other words, for this workload the stability requirement (c > a) is the binding constraint, not the latency SLO, the moment you add the one server needed for the queue to be stable at all, the latency target is already satisfied with room to spare. That's a genuinely useful finding, not a hedge: it tells you the 100 ms target isn't driving headcount here, queueing stability is.

ML-inference service: the absolute stability floor is 9 replicas (offered load of 8), but at 9 replicas the wait is about 26 ms, over the 15 ms target. Here the latency SLO (Service Level Objective, the internal performance target you commit to) is the binding constraint, not stability, so one additional replica (10 total, utilization 80%) is needed to hit the target. This is the more typical shape for a tight-latency SLA (Service Level Agreement, the target the system is contractually held to): you provision noticeably below the theoretical maximum utilization to keep queueing delay in check.

Limitations of M/M/c for real production systems

• Exponential (memoryless) assumptions rarely hold. Real service times are often more variable (heavy-tailed) than exponential, which makes actual queueing worse than Erlang C predicts at the same utilization; M/G/c (the same queueing model but with general, non-exponential service times) or simulation is more realistic when service-time variance is high.
• Arrivals are rarely a pure Poisson process (the formal name for the memoryless, random arrival pattern already described above). Real traffic has autocorrelation and burstiness (a retry storm, a batch job kicking off) that a memoryless arrival process doesn't capture, understating tail risk.
• Servers are assumed identical and always available. Real fleets have heterogeneous instance performance, warm-up/cold-start effects, and servers going in and out of service, none of which this model accounts for.
• It models only queueing delay, not the full latency picture. Network hops, downstream dependency calls, and GC (garbage collection, the runtime automatically reclaiming unused memory) pauses aren't part of this model at all.

The practical takeaway: use Erlang C for a first-pass, order-of-magnitude sizing estimate and to build intuition for how utilization drives tail latency, then validate the real number with a load test before committing to it as a capacity plan.

Proving that a technology change improved reliability, cost, or developer velocity requires the same discipline as any causal claim: a baseline captured before the change, a comparison that isolates the change from everything else happening at the same time, and a report that states the uncertainty honestly instead of presenting a single before-and-after number as fact.

Baseline, control, and rigor

Capture the baseline before the change ships, not after. Record the metric over a period long enough to see its natural variation (commonly 4 to 8 weeks, or long enough to span at least one full business cycle such as a weekly or monthly peak), because a single pre-change data point cannot tell you whether post-change movement is the change or ordinary noise.

Use a control where one is available, and be explicit when one is not. The strongest design is a staged or canary rollout, where part of the traffic or part of the team migrates first while the rest continues on the old system under identical external conditions during the same window; this isolates the change from confounders like a holiday traffic dip or an unrelated incident elsewhere in the stack. When a true control is impossible (for example a single monolith-wide platform migration with no way to run half the org on the old system), say so explicitly and rely instead on an interrupted-time-series comparison: the same metric, same team, same season, immediately before and after, with any known confounding event during the window called out by name rather than absorbed silently into the result.

Pick metrics that match the claimed benefit, and use more than one. For reliability: incident count and mean time to recovery, plus the error-budget burn rate against the service's service-level objective, or SLO (the reliability target you've committed to, for example 99.9% uptime per month). An error budget is the amount of allowed failure that target implies (0.1% of the month, in this example), and the burn rate is how fast you're consuming it: a rate of 2x means you're on pace to use up a month's entire allowed failure in half a month, which is the signal most teams use to slow down risky changes. For cost: total infrastructure spend normalized per unit of traffic or per customer, not raw spend, since raw spend conflates cost efficiency with growth. For developer velocity: deployment frequency, lead time for changes (time from commit to production), and change failure rate, three of the four metrics the DevOps Research and Assessment (DORA) research program tracks (the fourth, time to restore service, is the same failure-recovery signal already captured above as mean time to recovery), plus a qualitative measure such as a developer survey on perceived friction, since a purely quantitative velocity number can improve while developer experience quietly worsens in a way the metric does not capture.

State statistical rigor honestly. Report the baseline period's own variance (for example "incident count varied between 3 and 9 per month in the six months before the change") alongside the post-change number, so a reviewer can judge whether the observed shift is larger than the system's normal noise, rather than reporting only two point estimates and letting the reader assume any difference is meaningful.

Worked example

A team migrates a service from self-managed virtual machines to a managed container orchestration platform, claiming it will improve deployment frequency. Baseline: over the 8 weeks before migration, the team shipped a median of 3 deployments per week, ranging from 1 to 6. They run a staged migration, moving one of three service instances to the new platform while the other two stay on the old one for the same 6-week window, so external factors (a product launch, a holiday freeze) affect both groups equally. Post-migration, the migrated instance's owning team ships a median of 9 deployments per week over that window, versus a median of 4 for the two teams still on the old platform during the identical window. Because both groups experienced the same external conditions, the roughly 2x differential (not the raw 3-to-9 jump, which could partly be a general uptick) is the number attributable to the platform change, and it is reported to stakeholders as "deployment frequency increased by approximately 2x relative to a matched control group over the same 6-week window," with the baseline range disclosed alongside it.

Trade-offs and pitfalls

The honest version of this analysis takes longer and produces a less dramatic headline than "deployments went from 3 to 9 a week," so there is real organizational pressure to skip the control and report the bigger, uncontrolled number; resist it, because a claim that does not survive a skeptical rereading damages the credibility of every future measurement from the same team. A common pitfall is picking the metric after seeing which one moved favorably, which turns measurement into storytelling; commit to the metric and the comparison design before the change ships. Reporting to stakeholders should lead with the plain-language claim and its confidence level, then the supporting numbers, since a wall of statistics with no headline is as ineffective as a headline with no statistics behind it.

Direct answer
Behavioral answer skeleton: describe a specific decomposition decision made (the boundaries chosen and why), what actually happened once it shipped (either it didn't go as planned, or it delivered a measurable improvement), and what that outcome revealed, whether a lesson learned from a setback or concrete evidence the decision was right.

Structured elaboration
A strong version of this story names the actual boundary decision (which service was split from what, and the reasoning at the time), not just "we adopted microservices." For the setback version: what specifically didn't go as planned (a boundary that turned out to force more cross-service coordination than expected, or a scaling assumption that didn't hold), how it was diagnosed (what signal first revealed the problem, whether an incident, a slow release cadence, or direct team feedback), and the concrete fix or the lesson carried forward (a corrected boundary, a new team-ownership model, or a changed process for validating boundaries before committing to them next time). For the success version: what was measured to confirm the decomposition actually delivered value, whether an increase in independent deploy frequency for the extracted service, a drop in incidents caused by unrelated changes to a previously-shared service, or a faster mean-time-to-recovery once the failure domain was smaller.

Worked example
A representative setback story: a service was split expecting two teams to be able to work independently, but the boundary was drawn along a technical line (splitting a read path from a write path) rather than a business-domain line, and the two resulting services turned out to need frequent, tightly-coordinated releases anyway because a business rule change usually touched both. The signal that revealed this was release velocity not improving the way the split was supposed to deliver, and cross-team coordination overhead showing up in retrospectives. The fix was re-drawing the boundary along the actual business domain instead of the technical read/write line, after which the two teams could genuinely release independently. A representative success story: extracting a reporting service from a shared order-processing service, after which order-processing's deploy frequency roughly doubled (no longer blocked by reporting's separate, slower release cycle) and a subsequent reporting-specific incident had zero impact on order processing, which was the exact goal the extraction was measured against.

Trade-offs and pitfalls
A weak answer to this question stays vague about what actually went wrong or right ("the migration was challenging but we got through it") without naming the specific boundary decision, the specific signal that revealed the outcome, or a specific number or concrete change that resulted; interviewers are listening for evidence the candidate can reason critically about their own past decomposition decisions, not just narrate that a project happened.