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

Not everything competes on the same axis. Treat the security patch as a gate, not a score: if it closes a live vulnerability, the downside of skipping it is not "worse than a feature," it is open-ended, a breach or a compliance failure, so it goes first regardless of what a weighted score says. With one slot left, score the remaining two candidates against a small set of criteria and let the arithmetic surface the trade-off you would otherwise be guessing at.

Structured elaboration

Step 1, separate gates from scored candidates. Does deferring this create unbounded or asymmetric downside, an active exploit, legal exposure, a safety issue? If yes, it is not really one of three competing priorities, it is a precondition. Fund it first and take the capacity hit on the other two.

Step 2, score what is left with a small weighted rubric using criteria that matter for the remaining choice specifically, not a generic checklist, and avoid double-counting risk the gate already absorbed.

Step 3, sanity-check the score against one thing it cannot see: what happens to the deferred item while it waits. An item deferred a second consecutive cycle is a different risk than one deferred once. If that is true, say so, and consider a smaller slice rather than zero.

Step 4, the explanation matters as much as the decision. Show the people who did not get picked the actual criteria and scores, not a vague "priorities shifted," acknowledge the specific cost of the delay to their work, and give a concrete checkpoint for when it gets revisited.

Worked example

Step 1: the security patch closes an actively exploitable gap, it is gated in regardless of score.

Step 2: score the remaining two candidates, weights: customer impact 35%, operational risk reduction 30%, effort (ease) 20%, strategic alignment 15%.

Decision: security patch, gated, plus the customer feature, 3.45 edges the refactor's 3.05, driven mainly by customer impact and effort. Step 3 sanity-check: the refactor's high operational-risk-reduction score, 5, means deferring it entirely is not free, so rather than zeroing it out, the smallest slice of the refactor that addresses the specific operational risk, the part actually driving on-call pain, gets pulled into the security work as a combined change instead of being shipped as a separate third initiative.

Step 4, explaining it: to the team that wanted the refactor, show the actual table, name the operational-risk-reduction score as the highest of the three so they know it was not dismissed, and commit to a specific point, the next planning cycle, where it is the first thing scored again, with the partial slice already delivered as a down payment.

Where this generalizes

The same two-step move, a gate for whatever cannot be traded away, then a weighted score for what's left, shows up any time a decision looks like several competing priorities but actually hides a precondition:

• A shortcut that will create tech debt: accept it or not, and what guardrails. Whether to accept the shortcut is the gate itself (does it violate a guardrail you have already committed to), and the guardrails are what keep a "yes" from turning into unmonitored risk.
• Evaluating a promising but immature third-party AI model vendor. Gate on the terms you cannot compromise on (data handling, an uptime floor), then score the remaining vendors on cost, roadmap fit, and support.
• Adopting a breaking new UI framework vs. extending the current one via a compatibility layer. Gate on whether the breaking change crosses a real migration-risk threshold, then weigh velocity, maintenance cost, and ecosystem support for what is left.
• Building an evaluation framework for scaling vertically vs. partitioning a dataset. The same weighted rubric applies, with the gate being whichever option would breach a hard operational ceiling, cost or latency, regardless of score.
• A long list of edge cases but only time for a minimal version. Gate on the edge cases that are correctness- or safety-critical, then rank the rest with a weighted severity-times-frequency score for what makes the cut.

Trade-offs and pitfalls

• Treating a genuine gate, active security exposure, as just another scored line item is how orgs end up trading away real risk for a slightly higher score elsewhere. Do not let the framework absorb decisions that should not be decided by weighted average.
• Deferring the same initiative every cycle without ever revisiting it, or shrinking it into a partial slice, converts "we'll get to it" into a standing risk nobody owns, which is exactly how large deferred refactors turn into outages.
• Explaining a deprioritization with vague language, "we had to make some calls," instead of showing the actual criteria reads as arbitrary and burns trust with the team that lost, even when the decision itself was right.
• Over-reading precision, treating 3.45 versus 3.05 as a wide gap, manufactures false confidence. That is a modest margin, worth naming honestly rather than presenting the call as obviously correct.

Clarify scope & assumptions

• Sprint = 2 weeks. Platform change A = 6 sprints (12 weeks) of core platform engineering by central team.
• A unlocks 8 product-level features across squads. If A isn’t done, each feature can be built as isolated work (B) taking ~1 sprint (2 weeks) of product squad effort each.
• Assume squads cannot all do features fully in parallel due to shared engineers; baseline: building 8 isolated features serially = 8 sprints = 16 weeks of cumulative engineering time (spread across squads).
• Assume each product feature yields incremental revenue of $10k/month (conservative) when live; discounting, no churn; platform change yields developer velocity, lower maintenance, and future feature cost reductions (quantified below).

Decision criteria

1. Business value: near-term revenue (B) vs. multi-product unlock (A).
2. Cost & schedule: total engineering time and blocking effects.
3. Strategic leverage: reuse, maintenance savings, onboarding time, time-to-market for future features.
4. Risk: technical debt, integration complexity, rollback surface.
5. Dependency & customer impact: are customers waiting for any single feature urgently?

Recommendation

• If >1 feature has urgent customer demand or high revenue (> ~$20k/month) → prioritize those specific B items immediately (short-term triage).
• Otherwise, invest in A when aggregate benefits (revenue unlocked + engineering savings) exceed B’s immediate revenue within 12–24 months. Given platform effects scale, favor A when roadmap includes >4 future features or long-term velocity matters.

Opportunity-cost estimate (choosing B over A for 1 year) — baseline numbers

• Immediate revenue from B (all 8 features) = 8 * $10k/mo * 12 = $960k ARR.
• Cost of engineering time (opportunity): 8 sprints of squad time vs. 6 sprints central time — roughly similar effort but more duplicated work. Estimate duplicated engineering/maintenance overhead = 20% extra annually = ~$150k cost.
• Value of A (conservative): faster development for future features — assume A reduces build time by 30% for 12 subsequent features next year, saving ~ (12 * average 1 sprint * 0.3) = 3.6 sprint equivalents => ~7 weeks of engineer time worth ~$70k. Plus lower maintenance/errors saving ~$100k. Plus cross-sell revenue unlocked by consistent UX = ~$200k.

Net: Choosing B yields $960k immediate ARR but foregoes platform benefits ($370k conservative). So opportunity cost of B over A ≈ $370k in measurable savings/enablement in year 1; adjust up if feature revenue or velocity gains are higher.

Sensitivity & next steps

• Run rapid financial model with real revenue per feature, engineering cost per sprint, and expected downstream features.
• Consider hybrid: deliver 1–2 highest-value B features while doing A in parallel (split 20/80) to capture urgent revenue and preserve platform leverage.

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

Push decision rights down to the people closest to the work by defining, up front, what is decided locally versus what escalates to you. Run a standing cadence that surfaces only exceptions rather than every choice, and watch your own queue as the leading indicator: if decisions are backing up waiting on you, the delegation boundary is wrong, not the team's competence.

Structured elaboration

1. Decision-rights matrix. Write down, before the program starts, which decisions each region or team owns outright and which require escalation.

2. Async by default. Regular status is written and read asynchronously, so your presence is not required for routine updates. Reserve synchronous time for cross-team conflicts or trade-offs that genuinely need real-time discussion.
3. Explicit escalation criteria. State in advance exactly what triggers escalation to you. Vague criteria ("check with me if unsure") make people escalate everything out of caution, which quietly recentralizes control even with a matrix on paper.
4. Self-check as the bottleneck signal. Track how many decisions route through you that did not technically need to, that is your bottleneck proxy. Track your own response latency on the things that do need you, that is whether escalation is actually faster than the team deciding alone.

Worked example

A program rolls out a platform change across five regions. Each region has a lead empowered to sequence their own migration steps and choose their own pilot cohort size, no escalation needed. What does escalate: anything that changes the shared migration contract every region depends on, or a slip in a region's committed date by more than one full cycle. With that split, in a typical month the only items that reach the program lead are contract questions and date-slip escalations, everything else is decided locally, so the lead's queue stays small enough to review a handful of exceptions rather than approve every regional decision.

Trade-offs & pitfalls

• Keeping all technical or scope decisions centralized "to stay consistent" recreates the exact single point of failure the delegation was meant to remove.
• Delegating the decision without delegating the context needed to decide well is a common miss: leads end up asking you for the same background repeatedly because it was never documented once, centrally, for everyone to reference.
• Junior candidates describe running more meetings to stay on top of everything. Senior candidates describe designing away the need to be present for most decisions in the first place.
• A vague escalation path is the most common pitfall: it looks like delegation on paper but produces the same bottleneck in practice, because everyone escalates out of caution rather than confidence.

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.