Non-Functional Requirements

The Pass That Decides Everything

FRs say what to build; NFRs decide what it is made of. This lesson converts RideShare’s qualities into measurable targets — the exact step most candidates skip and every interviewer probes.

Method: For Each FR Cluster, Ask the Five Questions

 1. SCALE     how many users/requests/data?
 2. LATENCY   how fast is "instant" per operation?
 3. AVAILABILITY  how much downtime is acceptable, per feature tier?
 4. CONSISTENCY   what divergence can users tolerate, per data type?
 5. DURABILITY    what data loss is unthinkable?

RideShare NFR Sheet (illustrative but internally consistent)

Data/Flow	Scale	Latency	Availability	Consistency	Durability
Location pings	~50k writes/sec peak	Async OK	99.9% (stale tolerated)	Last-write-wins	Ephemeral — loss acceptable
Ride match	~600 matches/sec peak	under 1s end-to-end	99.95%	Strong on trip record	Zero acknowledged-trip loss
Payments	follows trips	seconds fine	99.99%	Strong, exactly-once capture	Absolute; audited ledger
Trip history	read-heavy, ~5k rps	p95 under 300 ms	99.9%	Eventual (seconds lag OK)	Permanent retention

Read the table as architecture decisions already made:

• Location’s write volume + ephemerality → in-memory store (Redis geo or similar), never the transactional DB.
• Match latency + consistency → matching reads fresh driver positions from memory, writes trip record transactionally.
• Payment row → strongest guarantees in the system; everything else may degrade before payments do.
• History being eventual → replicas + cache serve it; no cross-region sync complexity needed.

Deriving the Numbers (not inventing them)

Each figure traces to an assumption stated earlier:

 10M DAU riders × 2 rides/day          = 20M trips/day
 20M ÷ 86,400 s                        ≈ 230 trips/sec average
 × 2.5 peak factor                     ≈ 600 trips/sec peak      → match QPS

 concurrent trips = 20M × 12 min / 1,440 min ≈ 170k active trips
 × 1 ping / 4 s                      ≈ 42k pings/sec avg ≈ 100k+ peak → location writes

Numbers derived this way defend themselves under pushback; invented ones collapse.

The Tiering Principle

Not all features deserve equal guarantees — tiering is where cost lives:

 TIER 1  payments        99.99%, strong consistency, full redundancy
 TIER 2  match/trips     99.95%, strong on records, multi-AZ
 TIER 3  history/social  99.9%,  eventual, standard setup
 
 uniform 99.99% everywhere roughly doubles spend to protect
 pages nobody audits at 4am

Interview Framing

The strongest opening-minute pattern remains: state scale assumptions, then derive two headline numbers live (peak QPS, storage/day) and pin them to a visible NFR table. When later asked “why Redis for locations?”, the answer is one finger-tap back to the table — reasoning that survives any follow-up.