Lyft System Design: What to Expect

Lyft runs system design as a fixture of the onsite. Mid-level loops carry one round of it. Senior loops often carry two, back to back, an hour each. You take a single prompt with one engineer on a shared canvas. The job is to move it from a blank screen to an architecture you can defend out loud. The level you interview at sets the bar. So does one fact about the prompt that most prep sites get wrong.

Lyft is a real-time geospatial marketplace, matching riders to drivers over live location, pricing surge, running each trip from request to drop-off. You would expect the prompt to be "design Lyft." It usually is not. The engineers who sit the round describe something more ordinary: a location search, a chat app, a payment flow, a crawler that re-syncs a large site. Interviewers have called their own question a typical one you could find on any prep channel. Some loops sit behind an NDA, so the public accounts stay vague about the exact wording. The signal underneath is steady even when the prompt is plain.

The Lyft angle

The prompt skews generic, so you prepare the marketplace underneath it. A location search sits at the core of dispatch. You take a rider's coordinates, find the nearby drivers, and rank them, while thousands of cars stream new positions every few seconds. Design that well and you have built the hard half of ride-sharing, whatever label the interviewer puts on the whiteboard. So rehearse the geospatial marketplace, not a memorized "design Uber" script. Learn how location is indexed for a fast radius query, how a write-heavy stream of driver pings stays apart from a read-heavy search, where a datastore choice pays off. The prompt may be plain. The system you reach for should be Lyft's.

How the round runs

The setup is plain. One prompt, one engineer, a shared drawing canvas, and roughly an hour to carry the design from nothing to a shape you can defend. What the interviewer wants on that canvas is concrete: a data model, an API, back-of-envelope capacity math, and a clean system diagram that ties them together. At senior level the loop can run this twice in a day, so the second design cannot lean on the energy of the first. No public prompt list or scoring rubric exists. Where a figure appears below, read it as a steer toward where practice pays, not a number Lyft stands behind.

• Format: One or two HLD rounds. System design shows up in nearly every mid-level and senior loop, about an hour each with one engineer on a shared canvas. Senior loops often run two design rounds in the same day.
• Level weight: Low-level early, high bar at T5. At T3 and T4 the round leans lighter and low-level, closer to modeling a component than scaling a fleet. At T5 and above it becomes a real high-level bar, and clearing it is decisive.
• On the canvas: Schema, API, math, diagram. A strong answer leaves four things behind: a data model, an API surface, back-of-envelope capacity math for memory and throughput, and a single diagram that connects them.
• Deep dives: Datastore choice and capacity. Expect the follow-ups to press on the datastore. One reported round went deep on why NoSQL, on the sharding key, and on the capacity math behind the numbers a candidate had quoted.

The prompts that come up

No single prompt owns this round the way a signature question might at another company. The reports scatter. What recurs is a small set of familiar systems, each of which hides a piece of Lyft's real stack once you look past the label.

• Geospatial: Location search. Index positions for a fast radius query, then rank what is nearby. This is dispatch with the ride-sharing label removed, and the most on-brand prompt of the set.
• Messaging: Real-time chat. A chat or messenger app, sometimes framed as Slack or WhatsApp. Fan-out, delivery guarantees, presence, message ordering. It also surfaces on the infrastructure sub-track.
• Payments: A payment flow. Framed once as accepting money for a charity pool. Idempotent charges, a ledger that always balances, and no double charge when a request retries.
• Distributed: A web crawler. Crawl and re-sync a large site, near enough to re-downloading all of Wikipedia. Dedup, change detection, plus the storage to hold it. A distributed-systems classic wearing a product hat.

The Lyft angle

Build toward "design a ride-sharing service," but know why it is here. It is the on-brand flagship and the thing people search for, so this section builds it in full. It is also more a prep-site prediction than a prompt candidates report. The accounts that name a real prompt point to a location search or a chat app, not "they asked me to design Lyft." Some of that is the NDA. Most of it is that the round tests the pieces, not the logo. So treat the ride-sharing design as the best single vehicle for those pieces: dispatch, geohashing, surge, the trip state machine. Learn those moves and they carry over to whatever prompt lands on the day.

The designs in this section

Two designs follow, and they split the work cleanly. The first is the ride-sharing flagship, where the geospatial marketplace gets built end to end. The second is a grounded classic, a real-time chat system or a standalone location search, both of them prompts engineers have reported here. Start with dispatch. It carries the most Lyft in it.

What the round rewards

The method is the standard one, aimed at Lyft's grain. Scope first: who the users are, what the read and write paths look like, how many riders and drivers and pings per second you are feeding. Sketch the API and the data model next, the handful of entities the system turns on. Draw the high-level path and say out loud which store sits behind each service and why. Then run the capacity math, because at Lyft the numbers bite. Millions of location updates a minute is a different database than a table of user profiles. Save room for the deep dive, since the senior round always has one.