Evaluation

In one line: one technique is credited for two requirements that trade against each other. Spotting that is the exercise.

Requirements compliance

Synchronous replication appears under availability AND consistency — it cannot serve both

The prose is explicit on both counts:

Availability: "The databases use a primary-secondary replication model with multiple replicas."

Consistency: "Our system does synchronous replication to achieve strong consistency."

Lesson 10 established the trade. Synchronous replication means the primary waits for secondaries before acknowledging a write, which buys no data loss on failover and costs write availability — a slow or unreachable secondary blocks writes.

So it is the technique that converts availability into consistency. Listing it as the answer to both is claiming both sides of a trade-off.

The accurate version scopes it, exactly as Lesson 2 argued the requirement should have been scoped:

Note that the design already splits its storage along exactly this line. The stores are right; only the evaluation's description fails to split with them.

There is a second claim in the consistency section worth engaging with, because it is a good argument:

"Because there are only a limited number of data writers and viewers for a trip (rider, driver, and some internal services), the use of traditional databases doesn't become a bottleneck."

That is genuinely right, and it is the best sentence in the evaluation. Strong consistency is affordable when the contention is low. A trip has two participants, so the cost of synchronous coordination is bounded — unlike, say, a celebrity's follower count, where every write contends with every other. Scope strong consistency to low-contention data and it stops being expensive.

Availability's real mechanism is the WebSocket reconnect, not the replicas

The prose names the mechanism the table omits:

"WebSocket servers are deployed to maintain persistent client connections. If a connection drops, the client reconnects through the load balancer and is attached to another healthy server instance."

That is the availability property that matters most here, because Lesson 4 established the connection tier is the whole interface: ride offers, trip updates, and location ingestion all flow through it.

Two things make it work, and both are worth naming:

The connection is stateless with respect to the server. A client can attach anywhere, because the trip state lives in the database rather than in the server holding the socket. If the WebSocket server were stateful, a failure would lose the trip.

Reconnection is client-driven. The client notices and retries; nothing on the server side has to detect and migrate anything.

That combination — stateful protocol, stateless servers — is what makes millions of long-lived connections survivable. It also, as Lesson 4 noted, requires a connection registry so that a ride offer can find the server currently holding a given driver's socket. The design never shows one, and without it the reconnect story is incomplete: the client can reattach, but the system cannot find it again.

Reliability is the one requirement met by something genuinely novel

"The trip can continue even if the rider's or driver's connection is broken. This is achieved by using their phones as local storage."

This is the most interesting claim in the evaluation, and it is correct. Lesson 10 covered the mechanism: the phone persists trip state and pending events, replaying them on reconnect.

Why it deserves emphasis: every other technique in the table — replicas, redundancy, load balancers — is standard and would appear in any design in this course. Using the client as a durable participant is specific to a system that controls physical actions, and it exists because the trip continues whether or not the network does.

It also cleanly separates the two requirements Lesson 2 said were worth separating. Replicas keep the system available; local persistence keeps the trip correct across a gap in availability. Those are different properties and this design has an answer for each.

Scalability's table is thinner than the prose

The table lists two techniques — sharding and Cassandra. The prose adds the ones that matter:

"The architecture decomposes functionality into independent services that can be scaled horizontally based on demand. Quadtrees partition the map into smaller regions, reducing the search space."

Service decomposition is the real answer, and Lesson 4 gave the reason: components differ by orders of magnitude in the lifetime of their work — 4 seconds for location ingestion, tens of minutes for trips, days for settlement. They must scale independently because their load profiles have nothing in common.

Missing from both table and prose is the technique the chapter actually spends its longest lesson on: the hash table in front of the quadtree, which cuts the index's write rate 3.75-fold. That is the single most important scalability decision in the design, and the evaluation does not mention it.

The same omission pattern as that building block, whose performance section credited caching and skipped the quadtree. When your evaluation omits the mechanism your chapter is built around, the evaluation is measuring something else.

What the design never addresses

Six gaps, in order of how likely they are to bite

No driver reservation during matching. Lesson 7's gap. Nothing prevents one driver being offered to two riders simultaneously. Needs a short-TTL soft lock, atomic in Redis. This is the one that breaks in production first.

No connection registry. Lessons 4 and 13. Ride offers are server-initiated and must reach one specific driver's socket, which requires a driver-to-server mapping. No component owns it.

No merge in the quadtree. Lesson 6. Drivers leave regions as constantly as they arrive, so cells that split during a peak never recombine, and the tree deepens permanently.

No timestamps in the schema. Lesson 9. Fare computation, fraud detection, and dispute resolution all need them, and none are stored. The Driver_location table records old and new coordinates but no time, so a trajectory can never become a speed — which Lesson 12's fraud detection specifically requires.

The MySQL-to-Cassandra handoff is a distributed transaction. Lesson 9. Completing a trip writes one store and deletes from another with no atomicity, so a crash leaves a duplicate or a lost trip.

The matching algorithm is one sentence. Lesson 7. Matching on distance rather than ETA, greedily rather than in batches, with no fairness constraints, is the part of the design a real ride-hailing company would consider its core product.

What the design gets right

Being fair, several decisions are genuinely good and worth affirming:

• The two-tier location scheme. Recognizing that "where is driver X" and "which drivers are near P" are different questions deserving different structures is the chapter's best idea.
• The polyglot split by lifecycle stage rather than by entity — mutable hot trips in MySQL, immutable cold ones in Cassandra.
• DeepETA predicting the residual rather than the ETA, which keeps the physics in the router and gives the system a fallback.
• Payments on an event log, with intent published before execution.
• Local persistence on the driver's phone, treating the client as a durable participant.
• Naming fraud as a requirement at all — a step up from that building block, where nothing defended against manipulation.

Only one of these is a correctness requirement rather than a performance one, and it is the one with a lock behind it. Saying which is which is more useful than listing mechanisms.

Interview signal by level

Next: the whole design under interview conditions.