Technical Product Manager Interview Preparation Guide - Lyft (Mid-Level)

Direct answer. A synchronous call with a long timeout is the simplest contract but scales worst and is the least reliable; asynchronous polling adds one extra round trip per check but is simple, universally supported, and tolerant of client disconnects; a webhook callback removes polling entirely but requires the client to run a reachable, publicly addressable endpoint; and a push mechanism (SSE or WebSockets) gives the lowest latency notification but costs a held-open connection per client and, unlike the other three, loses events outright across a dropped connection unless you deliberately design around it.

Synchronous, long-timeout call. Contract: the client makes one request and the connection stays open until the operation finishes. Simplest to implement and to consume, but it ties up a connection (and, usually, a worker thread or process) on both ends for the full duration, does not survive a client disconnect or a load-balancer's own idle-connection timeout, and gives the client no way to check progress or cancel while waiting. Reasonable only for operations that reliably finish in a few seconds.

Asynchronous polling. Contract: POST starts the job and returns 202 Accepted with a Location header pointing at a status resource; the client GETs that resource repeatedly until it reports a terminal state. Trade-off: an extra round trip per check, and the client has to decide a polling interval (too frequent wastes both sides' resources, too infrequent adds latency to when the client learns of completion), but it needs no special client-side networking capability (any client that can make a plain GET can poll) and survives a client disconnecting and reconnecting later, since the job's state lives independently on the server.

Webhook callback. Contract: the client registers a callback URL at job-submission time; the server POSTs the result to that URL once the job completes, with the usual webhook discipline (signing the payload, retrying on delivery failure, the client acknowledging receipt). Trade-off: removes polling entirely and notifies the client the instant the job finishes, but requires the client to operate a publicly reachable HTTP endpoint capable of receiving the callback reliably, which is a real operational burden a purely client-side application (a mobile app, a browser tab) usually cannot meet at all.

Push (SSE or WebSockets). Contract: the client opens one connection and receives job-status events pushed over it as they happen, no polling and no callback endpoint needed on the client's side. Trade-off: lowest latency notification of the four options, but the server has to hold one open connection per subscribed client for as long as they care about updates, which is real, ongoing resource cost per client (unlike polling, whose cost is bounded and predictable, or webhooks, which cost nothing while nothing is happening) and this cost scales linearly with the number of simultaneously-watching clients, not with how many jobs are actually running. Reliability is the real weak point of this option specifically: if the connection drops mid-job (a mobile network hiccup, a laptop sleeping), any event pushed while disconnected is simply lost, unlike polling (the next poll just re-reads current state) or a webhook (the server retries delivery). SSE mitigates this with a built-in Last-Event-ID mechanism so a reconnecting client tells the server where it left off and missed events can be replayed; a raw WebSocket has no equivalent built in and needs the same idea implemented by hand. In practice, push is usually paired with a fallback GET on the status endpoint after a reconnect, so a client that missed an event still converges on the true state instead of silently believing stale information.

Choosing. Reach for polling as the default (works everywhere, no special client capability required); reach for a webhook when the caller is itself a server-side integration that can reliably host a callback endpoint; reach for push only when true low-latency notification to many simultaneously-connected clients is a real product requirement (a live collaborative dashboard), since it is the option with the highest ongoing server cost per client and the one most in need of an explicit reconnect-and-reconcile plan.

Direct answer: Start by ruling out measurement problems before concluding the feature genuinely failed: confirm the trial was correctly instrumented and reached the population it was supposed to, then look at whether the trial changed intermediate behavior (engagement during the trial) even without changing the final conversion outcome, since a flat overall result can hide a mix of the trial working for some users and failing for others.

Structured elaboration

1. Rule out instrumentation and eligibility issues first: confirm the trial actually reached the intended audience, that trial-start and trial-end events fired correctly, and that the population offered the trial matches who the feature was designed for; a "no uplift" result caused by half the eligible population never actually seeing the trial offer is a data problem, not a product problem.
2. Check intermediate engagement, not just the final outcome: look at whether trial users engaged with the product's core value during the trial at all; if engagement during the trial was low, the problem is likely the product experience itself (the trial did not showcase enough value to justify paying), not the trial mechanic; if engagement was high but conversion still did not follow, the problem is more likely priced or positioned wrong at the conversion moment itself.
3. Segment before concluding "no effect" uniformly: a flat aggregate result can mask a real positive effect for one segment offset by a real negative or neutral effect in another (e.g., the trial converts well for users who came from a specific acquisition channel but not at all for a lower-intent channel); this doesn't require full statistical methodology, just an honest look at whether the population is genuinely homogeneous with respect to the trial's mechanism.
4. Decide the next step from what you found: if the trial-engagement was low, iterate on showcasing value earlier in the trial; if engagement was high but conversion was not, iterate on the pricing or the conversion prompt itself; if neither engagement nor conversion moved for any segment, and the trial reached its intended audience correctly, that supports the harder conclusion that this offer genuinely does not move this audience, and abandoning or fundamentally redesigning the approach is warranted.

Worked example: A design tool's 14-day trial shows no lift in paid conversion. Checking instrumentation confirms the trial reached the intended free-tier population correctly. Checking intermediate engagement shows trial users used significantly more premium features during the trial than free-tier baseline users, meaning the trial DID succeed at getting people to experience the premium value. But conversion at trial-end was still flat, pointing the diagnosis toward the conversion moment itself (the pricing page, the reminder timing, the offer clarity) rather than toward the trial mechanic or product value being the problem. The recommended next step is iterating on the trial-to-paid conversion flow specifically, not abandoning the trial concept.

Trade-offs and pitfalls: The most common mistake is treating a flat top-line result as conclusive proof the trial concept failed, without checking whether the trial worked at the engagement layer even though conversion did not follow; that distinction changes the recommended fix entirely. The opposite mistake is over-segmenting a small sample until some subgroup shows a positive number by chance, and treating that as proof of a hidden win; any segment-level finding needs a plausible mechanism, not just a favorable split.

Direct answer

Turn "handle spikes" into numbers by asking for the spike multiplier over baseline, its duration and arrival shape, the peak concurrency it implies, and what is allowed to degrade versus what must stay within the service-level agreement (SLA) during it. Those four answers are what actually let you size autoscaling, connection pools, and a degradation plan; without them, "handle spikes" is a feeling, not a requirement.

Structured elaboration

The four questions that make it measurable

The general skill, applied to a different vague ask

The same discipline works on any vague requirement, not just traffic spikes. "Handle a fifteen-year-old legacy system with no APIs" is exactly as unmeasurable until you ask the analogous questions: what data-access surfaces actually exist (direct database reads, nightly file exports, screen automation), who owns changes to that system, what staleness is tolerable in whatever gets extracted, and what happens to your system if that legacy system goes down for a day. "No APIs" becomes a concrete integration contract the same way "handle spikes" becomes a concrete capacity contract, by naming the constraint that changes the design instead of accepting the vague label.

Worked example: turning "5x for ten minutes" into a server count

Assume measured baseline steady-state traffic of 1,000 requests per second (RPS), and product says the spike is "5x for about ten minutes." Assume each server instance safely handles 200 RPS at target latency:

$$\text{baseline servers} = \frac{1{,}000}{200} = 5$$ $$\text{spike RPS} = 5 \times 1{,}000 = 5{,}000$$ $$\text{spike servers needed} = \frac{5{,}000}{200} = 25$$

Now check whether autoscaling can even react in time. Assume it takes 3 minutes from scale-out trigger to a new instance serving traffic:

$$\text{spike duration (10 min)} > \text{scale-out reaction time (3 min)}$$

Autoscaling alone is workable here, with roughly 3 minutes of degraded capacity at the start of the spike. If the same 5x spike instead lasted 60 seconds (a flash-crowd shape rather than a sustained one), the 3-minute scale-out reaction time would exceed the entire spike duration, and the only real fix is pre-warmed standby capacity, not faster autoscaling. That is why duration and arrival shape change the design, not just the multiplier.

Trade-offs & pitfalls

• Pitfall: designing for "handle any spike" instead of a bounded one. Every system has a ceiling; the point of these questions is choosing it deliberately instead of discovering it during an incident.
• Pitfall: assuming autoscaling reaction time is negligible. If it is not faster than the spike itself, pre-provisioned headroom is needed, which costs money sitting idle.
• Graceful degradation (returning cached or partial results, shedding low-priority requests) is usually cheaper than provisioning for the absolute peak, but only if product has said which features are allowed to degrade.

Direct answer

Build the rollout decision as an incremental cost-per-conversion calculation validated by the test's own conversion data, not assumed from general latency-performance literature. Require the conversion lift to be statistically significant with adequate sample size before trusting it, then weigh the incremental dollars per conversion against a known comparator, such as the existing acquisition cost per conversion, along with non-dollar costs like operational complexity and reversibility before deciding on a global rollout.

Structured elaboration

Business metrics to correlate with performance: conversion rate is the primary one, latency and conversion are one of the best-established relationships in web performance; also track bounce rate, session depth, and revenue per session, since a small conversion uptick can mask a shift in average order value that changes the net picture.

Incremental cost per conversion:

$\text{incremental } \$/\text{conversion} = \frac{\Delta \text{monthly cost}}{\Delta \text{monthly conversions}}$

This is the marginal dollar cost of buying one additional conversion through this latency change. Comparing it against the business's existing customer acquisition cost via paid marketing is a useful sanity check, if buying conversions this way is cheaper than the existing channel, that favors rollout.

Statistical significance and power: pre-register the minimum detectable effect (the smallest true conversion-rate lift the test needs to be able to reliably catch) for conversion rate before the test, informed by the actual business value at stake rather than a round number, compute the required sample size at standard power (the probability the test detects a real effect if one truly exists, commonly targeted at 80%) and confidence, and do not stop early on a favorable interim result without a correction for repeated looks.

Non-functional costs beyond the dollar figure: operational complexity (new infrastructure to monitor and support on-call), reversibility (how hard is rollback if the lift does not hold up at full scale or in a different season), opportunity cost of the engineering time spent, and risk concentration (does the extra cost rely on scarcer or more fragile instance types that are harder to scale under a spike).

Worked example

Test: variant A, 30% lower p95 latency, 40% higher monthly infrastructure cost, run 50/50 for 3 weeks, roughly 2,500,000 sessions per arm.

Baseline conversion rate 3.20%, so 2,500,000 × 0.032 = 80,000 conversions in the baseline arm. Variant A conversion rate measured at 3.45%, so 2,500,000 × 0.0345 = 86,250 conversions.

$SE_{\text{diff}} = \sqrt{\frac{p_1(1-p_1)}{n_1} + \frac{p_2(1-p_2)}{n_2}}$

SE (standard error) here measures how much the observed 0.25-point difference would naturally bounce around by chance if the test were repeated. With p1 = 0.032, p2 = 0.0345, n1 = n2 = 2,500,000: SE ≈ 0.00016 (0.016 percentage points), so a 95% confidence interval half width of about 0.00031 (0.031 percentage points). The observed difference, 0.25 percentage points, is about 8 times that confidence-interval half width, comfortably outside it, and about 16 times the standard error itself (0.25 / 0.016 ≈ 15.6, a z-score, the number of standard errors the observed difference sits from zero), a highly significant result, well beyond what a pre-registered minimum detectable effect of 0.3 points would have required for the test to be adequately powered.

Extrapolating the measured lift to full monthly traffic of 5,000,000 sessions: incremental conversions = (0.0345 − 0.0320) × 5,000,000 = 12,500 additional conversions a month. Incremental cost = 0.40 × $200,000 baseline infrastructure cost = $80,000/month.

Incremental cost per conversion = $80,000 / 12,500 = $6.40. Against an illustrative existing marketing acquisition cost of $9.00 per conversion, $6.40 is cheaper, a strong quantitative signal favoring rollout, assuming the lift and the cost ratio both hold at full scale.

Trade-offs and pitfalls

Extrapolating a test's lift to 100% of traffic assumes the effect is uniform and does not decay, for example from a novelty effect, or that the test population resembles full traffic, validate with a staged rollout rather than jumping straight to global. The marketing-cost comparator is a useful sanity check, not a like-for-like comparison, marketing acquires new users while a latency improvement better converts existing traffic, state that distinction rather than treating the two numbers as interchangeable. A significant lift measured at test scale does not mean the cost ratio holds forever, if traffic grows, the 40% cost increase scales too, re-validate the ratio at the new scale. Non-functional costs like operational complexity or reduced reversibility do not show up in the dollar math at all and can outweigh a favorable cost-per-conversion number.

Direct answer

Data-residency and regulatory freshness requirements turn caching from a pure latency/consistency trade-off into one that also has to respect WHERE data is allowed to live and how quickly compliance-relevant staleness must resolve, which can rule out otherwise-attractive designs (like replicating everything everywhere) outright.

Structured elaboration

• Regional constraints on data placement: tenant or user data that must remain in-region (a legal requirement, not just a latency preference) cannot simply be cached at a global edge location or replicated to every region "for performance"; the caching architecture must respect the same residency boundary the primary datastore does.
• Serving cross-region reads for public/non-restricted data: not all data is subject to residency rules; separate the caching strategy for tenant-restricted data (region-locked caching only) from genuinely public data (which can use normal multi-region caching without constraint).
• Freshness windows as a compliance requirement, not just a UX one: when a regulation specifies reads must be within a bounded freshness window (e.g., for financial or health data), the caching design must be able to prove that bound is met, which usually means favoring push-based invalidation with monitoring over a purely best-effort time-to-live (TTL), and having a fallback (bypass cache, read the source of truth) when the bound cannot be confirmed.
• A framework balancing throughput, cost, and staleness risk: quantify the cost of NOT caching (read latency, backend load) against the cost of a compliance violation (which is often not proportional to the staleness amount, it can be a fixed, severe cost regardless of whether staleness was 1 second or 10); this asymmetry usually justifies erring conservative (shorter TTLs, more monitoring, a documented fallback path) for regulated data even at some throughput cost.
• Contingency triggers: define what happens if freshness monitoring shows the actual staleness has exceeded the regulatory bound (e.g., automatically bypass cache and serve directly from the source of truth until the pipeline catches up, and alert the compliance/engineering owners).

Worked example

A service with users in the European Union (EU) requiring their data to stay within EU infrastructure: application caches for EU users are deployed only in EU regions, with no replication of that specific tenant data to non-EU regions even for read-performance reasons; a global feature like public product catalog data (not subject to residency) can still use the normal, unrestricted multi-region caching design, with the two data classes' caching pipelines kept clearly separated in the architecture so a future change to one cannot accidentally leak the other's constraint.

Trade-offs and pitfalls

Treating data residency as "just another latency consideration" rather than a hard constraint risks an actual compliance violation, which typically carries fixed, severe cost regardless of how small the violation was; design residency boundaries as non-negotiable constraints the caching layer must respect, not as one more variable to optimize against latency. Mixing regulated and non-regulated data in the same caching pipeline without clear separation makes it easy for a future change to accidentally violate the residency boundary; keep them architecturally distinct.

Direct answer
Say plainly that you don't know, in one sentence, then say what you'll do about it and by when. Guessing out loud in front of a senior leader is far riskier than a confident "I don't have that number, I'll confirm and follow up today."

Structured elaboration
The response has two parts that both matter: the admission itself needs to be brief and undefensive, not padded with excuses about why you don't know; and the commitment needs to be specific, a concrete action and timeframe, not a vague "I'll look into it." A specific commitment ("I'll have that number to you by end of day") reads as competence, because it shows you already know how you'd get the answer, even though you don't have it yet.
Afterward, two things matter as much as the in-the-moment answer: actually following up by the time you committed to, and, if the question reveals a real gap in what you track or know, treating that as useful signal rather than something to quietly forget once the meeting ends.

Worked example
An executive asks a data engineer, mid-briefing, what the current data-freshness SLA (service-level agreement) breach rate is across all pipelines, a number the engineer hasn't pulled recently. Rather than estimating, they say: "I don't have that broken out by pipeline right now, I can pull the exact number and have it to you within the hour." They follow up as promised, and separately note that the question itself suggests this metric should probably be on the standing dashboard rather than something they have to look up each time it's asked.

Trade-offs and pitfalls
The most damaging failure is guessing with false confidence and being wrong later, which costs far more credibility than the honest admission would have. A milder but still real failure is over-apologizing for not knowing, which draws more attention to the gap than a brief, matter-of-fact admission would.

Bottom line

Don't debate this on taste. Split it into two separate questions, get a cheap, fast read on each from data you likely already have, and only then compare the two using a rough return-on-investment (ROI, value created per unit of effort spent) estimate.

How to decide

1. Separate the two failure modes the callout and the backend work each fix:

   • The callout fixes a discoverability problem: people never find or try the feature.
   • The backend work fixes a quality problem: people find it, but it disappoints them once they use it.
     A feature can suffer from either, both, or neither, and the fix only works if it targets the actual bottleneck.

2. Pull cheap signals before guessing, all things you can usually get from existing analytics and support data in a day or two, with no new code:

   • Funnel data: of all active users, what percent ever open the feature (tells you if discoverability is the bottleneck), and of those who open it, what percent complete it or return to it (tells you if quality is the bottleneck).
   • A quick read of 30 to 50 recent support tickets or session recordings tagged to the feature, to see whether drop-off looks like people getting lost in the navigation versus people hitting an actual defect or a "this isn't good enough" moment.

3. Turn those signals into a rough ROI comparison:

$\text{ROI} = \frac{\text{expected incremental value}}{\text{engineering cost}}$

Expected incremental value is roughly (number of additional or improved conversions the change would produce) times (value per conversion). Engineering cost is the effort, in developer-weeks, for each option. You don't need precision here, you need the two ratios to be different enough to point clearly one way.

4. If the two ROI estimates are close, don't force a binary call: a small, fast experiment for each (a feature-flagged callout to a slice of traffic, and an equally-scoped fix for the top quality complaint) settles it with real data faster than another round of debate.

Worked example

Say a trip-planning app has 100,000 monthly active users, and a cost-splitting feature is buried three taps deep. Funnel data shows only 4% of users ever open it (4,000 people), and of those, 55% complete it (2,200). That split alone is informative: 96% of users never even see the feature, which points at discoverability as the bigger-volume bottleneck.

Suppose a similar UI callout shipped in another part of the product previously lifted a comparable feature's open rate from 4% to 9%, a real precedent to anchor the estimate on. Applied here, that's roughly 5,000 additional openers a month, and if completion rate holds at 55%, about 2,750 additional completions a month.

Now the backend option: support tickets show a specific failure (splits don't handle uneven groups well) affecting a chunk of users who try to complete the flow. Suppose fixing it would lift completion rate among the existing 4,000 openers from 55% to 70%, that is 4,000 x 0.15 = 600 additional completions a month, from the same audience size that already exists today.

At comparable engineering cost (call it one sprint for either option), the callout produces roughly 4 to 5 times more additional completions by volume. On pure ROI, the callout wins here, but that number alone isn't the whole decision.

Trade-offs and pitfalls

• A callout is more visible and more demoable, which biases people toward preferring it in a review even when the numbers say otherwise. Don't let "which one is easier to show off" substitute for "which one the data supports."
• If the feature genuinely has a quality problem, driving more traffic into it with a louder callout can backfire: more people try it, more people bounce or leave frustrated, which can hurt overall app ratings even as the "open rate" metric goes up. When completion quality is clearly broken, it's often safer to fix or at least de-risk that first before spending a scarce, high-visibility UI slot to drive volume into it.
• A prominent callout also has an opportunity cost: that UI real estate could be promoting something else, so the comparison isn't really "callout vs. backend," it's "this feature's callout vs. everything else that wants that same spot."
• This doesn't have to be all-or-nothing. If both problems are real and the effort is divisible, a smaller version of each (a modest UI nudge plus a scoped fix for the worst quality complaint) can capture most of the value without betting the whole sprint on one lever.

Direct answer

A lift that spikes in week one and fades to flat by week two could be three different things wearing the same shape: a real novelty effect decaying to its true (smaller or zero) persistent level, a seasonal pattern that has nothing to do with the treatment and would show up in both arms if you looked, or a selection-bias artifact where the traffic source itself (a holiday push or a marketing campaign) skewed an unrepresentative mix of users into treatment. The fastest way to tell them apart is to check whether the decay tracks calendar time (seasonality), user exposure-age (novelty), or arm composition (selection bias), because each explanation leaves a distinct fingerprint in the data, not just a distinct story.

Structured elaboration

The checklist, in order

Disentangling novelty from selection bias when a marketing campaign is the traffic source

This case is harder because both explanations can be true at once and produce the same decaying shape. A marketing campaign that ramps down after week one changes who is arriving, not just how they behave: if campaign-driven traffic is disproportionately assigned into treatment (for example because the campaign linked directly into the treatment experience, or assignment happened downstream of a referral parameter correlated with arm), the week-one spike partially reflects a different, more click-happy population rather than a within-user novelty effect.

• Design fix: randomize on a unit and at a point in the funnel that is independent of campaign exposure, assigning before the user ever sees the campaign-specific landing experience, so acquisition-channel composition is balanced by construction rather than by hope.
• Post-hoc check: compare the new-vs-returning mix and traffic-source mix between arms week by week; if the treatment arm's share of campaign-driven new users is higher than control's, run a balance check on that specific subpopulation, not just the top-line allocation.
• Post-hoc correction: re-run the primary analysis restricted to users who arrived through non-campaign channels, and separately on campaign-driven users; if the effect concentrates in the campaign-driven segment and that segment is imbalanced between arms, the pooled week-one number is not a trustworthy estimate of the treatment effect for the general population.

Redesigning the experiment or analysis window

• Extend the primary analysis window well past the campaign's active period so the segment mix has time to normalize, and pre-register that the primary readout is a later window, not week one.
• Use a difference-in-differences framing (treatment-arm change from a pre-period baseline, minus control-arm change over the same calendar span) so genuine calendar movement common to both arms cancels out instead of being misread as a treatment effect.
• If holiday timing cannot be avoided, consider a staggered or replicated launch (the same treatment introduced to a second, non-holiday cohort later) so you get a second read that is not confounded with that specific calendar event.

Worked example

Suppose the pooled week-one lift is +8% on a baseline conversion rate of 10%, and segment analysis shows the treatment arm received 60% campaign-driven new users in week one versus 40% in control (stated, illustrative inputs). If campaign-driven new users convert at a naturally higher rate, say 14% versus 9% for organic users (illustrative inputs), the arm-level blended rate is a weighted average:
$\text{Treatment rate} = 0.6 \times 0.14 + 0.4 \times 0.09 = 0.084 + 0.036 = 0.120$
$\text{Control rate} = 0.4 \times 0.14 + 0.6 \times 0.09 = 0.056 + 0.054 = 0.110$
That gives an apparent lift of $(0.120 - 0.110)/0.110 \approx 9.1\%$, almost entirely explained by the composition difference rather than any within-user treatment effect, before even considering a real novelty component. This is why segment analysis has to run before you trust the topline number, not after.

Trade-offs and pitfalls

• Restricting analysis to non-campaign traffic to remove selection bias also shrinks your sample and can push you back into an underpowered read, exactly what the power-review step is meant to catch.
• Difference-in-differences assumes both arms would have moved in parallel absent the treatment; a campaign that specifically targets one arm's users breaks that assumption too, so DiD is not a free fix if the selection bias operates through campaign-to-arm assignment rather than through time.
• Extending the window to wait out both seasonality and novelty delays the launch decision; be explicit with stakeholders that "flat by week two" was never a valid stopping rule for this scenario, so the delay does not read as backpedaling.
• Retiring a variant because week two looks flat, without a power review, risks killing a real but modest persistent effect that a two-week window was never sized to detect in the first place.

Situation: I was presenting a rollout plan, and I noticed the room was quiet in a way that felt like confusion, not agreement. People kept saying "looks fine," but decisions were slowing down afterward.

Task: I suspected my style was not landing, so I wanted honest feedback before the pattern hurt delivery.

Action: I asked my teammate for a direct read after the meeting and made it safe to be candid. I said, "I think I'm giving too much context and not enough clear recommendation. What part lost you?" They told me I was burying the decision in details. I changed my approach by leading with the recommendation first, then giving only the two or three facts needed to support it. I also started ending meetings with "here is the decision, here is the owner, here is the deadline."

Result: My follow-up meetings became shorter and decisions were clearer. The main thing I learned was that feedback is useful when I ask for it early, not after a pattern turns into a problem.

Direct answer
An API is a defined contract that lets one piece of software request functionality or data from another without knowing its internals, and the choice between REST, GraphQL, and gRPC shapes real product trade-offs in how the API evolves, performs, and feels to integrate with, not just a technical preference.

Structured elaboration

• REST: models the API as a set of resources accessed via standard HTTP verbs, with each endpoint typically returning a fixed response shape. Practical consequences: versioning is straightforward (path or header-based, as widely understood), caching works naturally with standard HTTP caching semantics since responses map cleanly to URLs, and it's broadly familiar to developers, lowering onboarding friction, but clients often over-fetch or under-fetch data relative to their exact needs since the response shape is fixed per endpoint.
• GraphQL: lets clients specify exactly which fields they need in a single query, often across what would be multiple REST calls. Practical consequences: reduces over-fetching and the number of round-trips for complex, nested data needs (valuable for mobile clients on constrained networks), but standard HTTP caching doesn't apply cleanly (most GraphQL traffic goes through a single endpoint via POST, requiring a different caching strategy), and it shifts real complexity to the server (query cost analysis to prevent expensive, poorly-formed client queries from overloading the backend). Versioning also works differently here: rather than shipping a new versioned endpoint, GraphQL typically evolves a single schema over time by adding new fields and marking old ones deprecated, which lets clients migrate at their own pace but requires disciplined schema governance so deprecated fields don't accumulate indefinitely.
• gRPC: a binary, contract-first protocol built for efficient service-to-service communication, typically not directly consumed by browser-based clients. Practical consequences: very low latency and efficient serialization, well suited to internal microservice communication or high-throughput client scenarios, but it requires generated client code from the service's defined contract (less flexible for ad-hoc, exploratory API consumption) and has weaker native support in web browsers. Versioning is tied directly to the protobuf contract: backward-compatible changes are typically made by adding new optional fields with new field numbers, while a genuinely breaking change requires a new service or package version, and clients must regenerate their stubs from the updated contract to pick up either kind of change, unlike REST's runtime-negotiable path or header versioning.

Worked example: a public-facing e-commerce order API with a broad, less sophisticated developer audience (small businesses integrating simple order creation and lookup) is well served by REST, since its familiarity and cacheability outweigh the modest over-fetching cost for simple resource access patterns. A mobile app's data layer aggregating a user's profile, recent orders, and personalized recommendations in a single screen load is well served by GraphQL, since it collapses what would be three or four separate REST calls into one request shaped exactly to the screen's data needs, reducing latency on a constrained mobile network.

Trade-offs and pitfalls
The most common mistake is choosing GraphQL primarily because it's newer or more flexible without accounting for the real backend complexity it introduces (query cost limiting, a different caching strategy), which can create more operational risk than the flexibility is worth for a simple API. The second common mistake is assuming the choice is permanent and irreversible; many platforms successfully offer REST and GraphQL as parallel interfaces over the same underlying services, serving each client type through whichever style fits its access pattern best.