Requirements

SLIDE 4: Section Intro, Requirements

Section 2: Requirements

In a system design interview, the first five minutes determine whether the interviewer sees you as someone who builds systems or someone who draws boxes. Requirements gathering is where you demonstrate that you design for specific constraints, not a generic system. A ride-sharing platform has requirements that are fundamentally different from a content platform like Instagram or YouTube: real-time location tracking, sub-second matching, concurrent state machines for millions of active trips, and strong consistency for payments at the scale of 20 million rides per day.

What We’ll Cover:

1. Clarifying questions: what to ask and why each question changes architecture
2. Functional requirements: rider, driver, and platform responsibilities
3. Non-functional requirements: latency, availability, consistency, and geographic constraints
4. Scope boundaries: what is in and what is explicitly out

Where Requirements Appear in Real System Design Interviews

Every section downstream depends on what you establish here. If you skip requirements and jump to drawing boxes, you will find yourself backtracking at minute 25 to answer “but how many users are we designing for?” That backtrack costs more time than the requirements phase itself. Requirements are not a formality. They are the inputs that determine every architectural output, from database selection in Section 8 to caching strategy in Section 12.

SLIDE 5: Clarifying Questions Before Design

Why Requirements Come First

The most common mistake in system design interviews is jumping straight to drawing boxes. The candidate says “Okay, so we need a microservices architecture with a load balancer…” before knowing whether the system serves 1,000 users or 100 million. The interviewer immediately marks this as a junior signal.

Architecture is a function of constraints. A ride-sharing platform serving one city with 5,000 drivers has a fundamentally different architecture than one serving 50 countries with 5 million drivers. You cannot make a single meaningful design decision without knowing the scale, the feature scope, and the consistency requirements.

What to Ask: Question Categories

The goal is 5-8 targeted questions. Each question should change at least one architecture decision. If a question does not affect architecture, it does not belong in a 45-minute interview.

How Many Questions Is Enough

Five to eight. Fewer than five and you are likely missing a constraint that forces a redesign mid-interview. More than eight and you are stalling. The interviewer wants to see that you ask the right questions, not every possible question.

Interview Tip:
Do not ask questions you can answer yourself. “How many users does Uber have?” is public information. Ask questions that require the interviewer to make a scoping decision: “Should we design for a single region or global deployment?” That question shows you understand the answer changes the architecture.

SLIDE 5B: Clarifying Questions, Specific Examples

Concrete Questions and Their Architecture Consequences

Each row below shows a question you would ask, the likely answer for a ride-sharing platform, and the specific architecture decision that answer drives.

The Pattern to Notice

Every question maps to a specific section of this course. When you ask “how fresh must driver location data be?” and the answer is “within 3-5 seconds,” you have just determined that the system needs a spatial index handling over a million writes per second. That single answer eliminates half the possible storage architectures.

SLIDE 6: Functional Requirements, Rider

Deriving Requirements from User Actions

Functional requirements are not invented from imagination. They are derived from what users actually do. Start with the rider’s journey through the app, and extract the system requirement behind each action.

Key Observation

The rider’s journey touches at least 8 distinct services. This is why a monolithic “RideService” that handles everything would become unmaintainable. Each action has different scale characteristics: “sees nearby drivers” is a spatial query backed by 1.25M updates/sec, while “rates driver” is a simple database write that happens once per trip. They need different infrastructure.

When listing functional requirements in an interview, the interviewer is evaluating whether you can decompose a user-facing product into system-level responsibilities. Saying “the rider can request a ride” is too vague. Saying “requesting a ride creates a trip record, triggers the matching pipeline to query the spatial index for nearby eligible drivers, and initiates a dispatch cascade with a 15-second acceptance window” shows you understand the system behind the feature.

SLIDE 6B: Functional Requirements, Driver

The Driver’s Interaction Model Is Fundamentally Different

A rider interacts with the system for minutes at a time: request a ride, track, pay, done. A driver interacts for hours: go online at 7 AM, receive dispatch offers throughout the day, navigate to pickups and destinations, complete trips, go offline at 5 PM. The driver’s session is a persistent, long-lived connection. This is why the driver app communicates primarily over WebSocket rather than REST.

Driver Actions as System Requirements

The driver goes online, which opens a WebSocket connection and begins streaming GPS every 3-4 seconds to the Location Service. That single action creates the dominant write load on the entire system: 5 million drivers streaming positions produces 1.25 million writes per second. This continues for the driver’s entire shift.

When a ride request comes in, the Matching Service queries the spatial index, scores candidates, and the Dispatch Service pushes an offer to the top-ranked driver via WebSocket. The driver has a 15-second window to accept. If they decline or the window expires, the offer cascades to the next candidate. On acceptance, the Trip Service updates the trip state to “matched” and the rider is notified.

The driver navigates to pickup (ETA Service + Maps API), arrives (trip state: driver_arrived), starts the trip (state: in_progress, metering begins), and completes it (state: completed, fare calculated, payment captured). Then the driver is immediately available for the next dispatch.

Scale Difference: Driver vs Rider

The critical architectural insight is the write volume asymmetry. A rider generates roughly 10 API calls per ride. A driver generates 3,000 to 10,000 GPS updates per shift. Multiply by 5 million active drivers, and the driver-side write load is orders of magnitude larger than the rider-side read/write load. This asymmetry is why the system needs a dedicated WebSocket Gateway separate from the API Gateway, and why the spatial index selection (Section 6) is the most architecturally consequential decision in the entire design.

SLIDE 6C: Functional Requirements, Platform

Platform Responsibilities: What Neither the Rider Nor the Driver Controls

The platform has responsibilities invisible to both the rider and the driver. These are the backend operations that keep the system running: tracking every active driver’s position, computing optimal matches, calculating dynamic prices, processing payments, and handling edge cases users never think about.

The Trip Service Is an Orchestrator

The rider sees “request a ride.” The driver sees “accept this offer.” Between those two actions, the platform executes a pipeline: query the spatial index for nearby drivers, filter by eligibility, score and rank candidates, send a dispatch offer over WebSocket, manage a 15-second acceptance window, handle decline or timeout, cascade to the next candidate, and update trip state at every transition.

The Trip Service coordinates this pipeline, calling Matching, Dispatch, Pricing, and Payment services in sequence. This orchestration pattern is not unique to ride-sharing. Any system with a multi-step workflow (e-commerce order fulfillment, food delivery, logistics) uses the same pattern. The Trip Service is a state machine coordinator, and understanding this pattern is directly transferable to other system design interviews.

Platform-Level Responsibilities

Beyond orchestration, the platform handles detection and recovery: TTL-based expiry on position records auto-offlines drivers who stop sending GPS, idempotent state transitions prevent double-booking, and event-driven processing via Kafka ensures downstream services (analytics, notifications, payment settlement) react to every state change without blocking the core ride flow.

SLIDE 7: Non-Functional Requirements, Latency

Real-Time Is the Defining Constraint

A ride-sharing platform is a real-time system. Not “real-time” in the marketing sense of “pretty fast,” but in the engineering sense of “if this operation exceeds a specific latency threshold, the user experience breaks in a visible, measurable way.” Instagram can serve a feed 500 milliseconds late and no user notices. If a ride-sharing platform takes 30 seconds to match a driver, the rider closes the app and opens a competitor.

Latency Is Not Uniform Across the System

This table reveals something important: the system does not have a single latency requirement. It has a spectrum. The spatial index query path needs sub-200ms response times, while payment authorization can tolerate 3 seconds. Different components need different infrastructure. The spatial index lives in Redis (in-memory, microsecond reads). Payment processing hits an external gateway over HTTPS with network latency included. Designing these two paths with the same technology or the same expectations would be a mistake.

This connects to Section 8 (Database Design), where we select different databases for different latency profiles, and Section 12 (Caching), where TTLs are set per data type based on these freshness requirements.

SLIDE 7B: Non-Functional Requirements, Geographic Availability

Data Locality: Queries Stay Local

A rider in Mumbai should never query a database in Virginia. Every operation in the core ride flow is geographically local: the rider, the driver, and the trip are all in the same city. This is fundamentally different from a social network like Instagram, where a user in India views content posted by a user in Brazil. In ride-sharing, there is no cross-geography data flow for the core product.

This locality has a direct architecture consequence: the system is partitioned by geography, not by user ID. All driver positions for Mumbai live in a Mumbai data center. All trip records for New York live in a US data center. When a rider in Mumbai opens the app, the request routes to the Mumbai cluster, which has everything it needs without talking to any other region.

Regional Independence

Each region operates as an independent unit. If the Mumbai cluster goes down, riders in New York are completely unaffected. Their requests never touched Mumbai infrastructure. This is a hard requirement for a global platform. A single failure in one country should not cascade to another country’s operations.

The exceptions are narrow: user account data (login credentials, payment methods) is global and replicated across regions so that a driver who travels internationally can still log in. But this global data is read-heavy, rarely updated, and small in volume compared to the location and trip data that stays local.

Interview Tip:
When the interviewer asks “how does this system work globally,” the answer is not “we replicate everything everywhere.” The answer is “the core ride flow is region-local with geographic partitioning, and only account-level data is replicated globally.” This demonstrates data locality, a senior-level concept that separates strong answers from generic ones.

SLIDE 7C: Non-Functional Requirements, Reliability and Fault Tolerance

Not Everything Needs 99.99%

Availability targets are not uniform across the system. The matching service needs the highest availability because it directly determines whether a rider gets a car. The analytics pipeline can tolerate hours of downtime without any rider or driver noticing. Assigning a single availability target to the entire system is a common interview mistake. A stronger approach is to tier services by business criticality.

Tier 1 (99.99% / ~52 min downtime/year):
  Matching, Dispatch, Trip Service
  Core ride flow. If these are down, no rides happen.

Tier 2 (99.9% / ~8.7 hours downtime/year):
  Payment, Pricing Service
  Can retry or fall back to base fare. Painful but not ride-blocking.

Tier 3 (99.95% / ~4.4 hours downtime/year):
  Location Tracking, Notification Service
  Can show slightly stale data or delay notifications.

Tier 4 (99.5% / ~1.8 days downtime/year):
  Analytics, Reporting, Admin Dashboard
  No rider or driver impact. Operational inconvenience only.

Graceful Degradation, Not Binary Failure

When a component is under stress or partially failing, the system should degrade gracefully rather than returning errors.

If the Location Service is slow, the Matching Service expands the search radius and uses slightly stale position data. The match may not be the closest possible driver, but the rider still gets a ride.

If the Surge Engine is down, the Pricing Service falls back to base fare pricing. The price will not reflect current demand, but the rider can still request and the driver still gets paid.

If the ETA Service cannot reach the Maps API, the system falls back to straight-line distance estimates with a buffer multiplier. Less accurate, but the rider sees an estimate rather than an error.

The pattern: serve a degraded result instead of no result. This connects to Section 13 (Trade-Offs and Failures), where we examine each failure scenario in detail.

SLIDE 7D: Non-Functional Requirements, Consistency Trade-Offs

Different Data Needs Different Consistency Guarantees

Not every piece of data in the system needs to be perfectly consistent at all times. Some data requires strong consistency because inconsistency causes real harm. Other data can tolerate staleness because the cost of being slightly behind is low. The system does not make one consistency choice globally. It makes a different choice for each data type based on the cost of getting it wrong.

Strong Consistency: Where Inconsistency Causes Harm

Matching and driver assignment require strong consistency. If two ride requests are processed simultaneously and both attempt to assign the same driver, exactly one must succeed and the other must find a different driver. A double-booked driver is a broken experience for everyone. This is enforced through optimistic locking in the Matching Service (Section 7).

Payment processing requires strong consistency. A rider must be charged exactly once for a completed trip. Authorization must be captured exactly once. Refunds must be idempotent. Enforced through ACID transactions in the Payment Service database (Section 8).

Eventual Consistency: Where Staleness Is Acceptable

Driver positions are eventually consistent by design. When a driver sends a GPS update, it takes milliseconds to low single-digit seconds to propagate to the spatial index. During that window, a nearby query might return the driver’s previous position. This is acceptable because a 3-5 second old position is still close enough for matching. The driver has not moved far in 3 seconds.

Ratings and analytics are eventually consistent. A new rating can take seconds or minutes to reflect in the driver’s average. No one is harmed by this delay.

SLIDE 8: Scope Boundaries

Drawing the Line: What You Will and Will Not Design

Scope boundaries are not about what the system cannot do. They are about what you will not spend interview time on. A ride-sharing platform has dozens of features. You have 45 minutes. Stating scope explicitly shows the interviewer you can prioritize, and it protects you from being pulled into a tangent about driver onboarding when you should be designing the matching pipeline.

In Scope: The Core Ride Flow

Everything needed to get a rider from “I need a ride” to “ride complete, payment processed.” This is the critical path that exercises the hardest system design problems.

Every node in this flow maps to a service we will design, a database we will choose, and a scaling decision we will defend.

Out of Scope: Stated Explicitly

These are real features that do not exercise new system design patterns beyond what the core flow covers.

• Driver and rider onboarding (registration, document verification, background checks)
• Admin tools and internal dashboards
• Fraud detection and prevention
• Detailed turn-by-turn routing (delegated to Maps API)
• Scheduled rides (adds a scheduling layer but does not change core architecture)
• Carpooling (multi-rider matching is a variant, not a fundamentally different system)
• Customer support and dispute resolution

How to Communicate Scope in an Interview

Say it once, clearly: “For this design, I will focus on the core ride flow from request to payment, including real-time location tracking, matching, dynamic pricing, and trip lifecycle management. I am scoping out driver onboarding, fraud detection, and scheduled rides, as those do not change the core architecture patterns.”

The interviewer may pull you into an out-of-scope area. That is fine. By stating your scope, you have demonstrated prioritization and given yourself permission to say “that is out of scope for this design” if a tangent arises.

SLIDE 9: Requirements Summary

Consolidated Reference: Everything Decided So Far

This slide is your screenshot. Everything established in this section, in one place.

Functional Requirements

Rider:    request ride, track driver, pay, rate
Driver:   go online, receive offers, accept/decline, navigate, complete trip, view earnings
Platform: track positions (1.25M/sec), match, price dynamically, process payments,
          manage trip state machine, handle cancellations

Non-Functional Requirements

Scope

Key Numbers Established

These numbers feed directly into Section 3 (Capacity Estimation), where we derive storage, bandwidth, and infrastructure sizing from them.

SLIDE 10: Wrong vs Right, Requirements Gathering

Common Mistake 1: Jumping Straight to Architecture

Wrong: “Okay, so I would use microservices with a load balancer, and we would have a matching service that uses Redis…”

The interviewer has not told you the scale, the scope, or the constraints. You are designing for a system you have not defined yet.

Better: “Before I start designing, let me ask a few clarifying questions to understand the scale and constraints we are working with.”

Common Mistake 2: Listing Too Many Features

Wrong: “The system needs ride requests, scheduled rides, carpooling, onboarding, fraud detection, customer support, loyalty programs, driver incentives, surge pricing, route optimization, toll calculation, airport queuing…”

Listing 15 features does not show breadth. It shows you do not know how to prioritize.

Better: “I will focus on the core ride flow from request to payment, including real-time tracking and dynamic pricing. I am scoping out onboarding, fraud, and scheduled rides as they do not introduce new architectural patterns.”

Common Mistake 3: Generic Non-Functional Requirements

Wrong: “The system should be fast, reliable, and scalable.”

Every system should be fast, reliable, and scalable. This tells the interviewer nothing.

Better: “Matching latency should be under 10 seconds end-to-end. Driver positions must be fresh within 3-5 seconds, which means ingesting 1.25 million GPS updates per second. Payments require strong consistency with exactly-once semantics.”

Common Mistake 4: Not Quantifying Requirements

Wrong: “We need to handle a lot of rides and a lot of driver location updates.”

Better: “At 20 million rides per day, we are looking at roughly 250 requests per second on average, with peaks around 700. But the dominant load is GPS updates: 5 million active drivers at a 4-second interval produces 1.25 million writes per second. That is 5,000 times the ride request volume, and it is the number that drives our spatial index design.”

SLIDE 11: Interview Practice, Requirements Pacing

Time Budget: 3-4 Minutes Total

Requirements should take 3-4 minutes of a 45-minute interview. This is long enough to demonstrate structured thinking and short enough to leave 40+ minutes for design. Spending 8 minutes on requirements is a red flag. Spending 30 seconds is a worse one.

Minute 0-1:     Clarifying questions (5-8 targeted questions)
Minute 1-2.5:   Functional requirements (rider, driver, platform)
Minute 2.5-3:   Non-functional requirements (latency, consistency, availability)
Minute 3-3.5:   Scope boundaries (in/out, stated once)
Minute 3.5-4:   Transition to capacity estimation

The Transition Sentence

Requirements end with a transition, not a pause. The interviewer should never have to ask “okay, what is next?” You tell them.

“Now that we have the scope and constraints, let me estimate the scale so we can make informed infrastructure decisions. We are looking at 20 million rides per day and 5 million active drivers, which gives us some key numbers to work with.”

This does three things: signals you are done with requirements, previews the next phase, and demonstrates that your requirements phase produced concrete numbers, not vague aspirations.

What the Interviewer Is Evaluating

They are not checking whether you asked the “right” questions. They are checking whether you can scope a problem before solving it, whether your requirements are specific enough to drive architecture decisions, and whether you can manage your own time. A candidate who spends 3 minutes establishing quantified requirements and then transitions cleanly is demonstrating exactly the structured thinking that distinguishes senior-level interviews.

How This Connects Forward

Every number from this section becomes an input to Section 3 (Capacity Estimation). Every functional requirement becomes a service in Section 4 (Architecture). Every consistency decision becomes a database choice in Section 8. Every latency requirement becomes a caching decision in Section 12. The requirements section is small in runtime but large in downstream impact.