Evaluation

In one line: three of the four requirement arguments are sound. The fourth is a non-sequitur, and it is the one worth spending time on.

Requirements compliance

The consistency argument is a non-sequitur — fault tolerance is not consistency

"Users have a consistent view... because we use reliable, fault-tolerant databases."

These are different properties and one does not imply the other.

Fault tolerance means the system survives node failure — through replication, which is exactly the mechanism that creates inconsistency, because replicas can diverge.

Consistency means all readers see the same value at the same time.

Far from supporting the claim, the design contains three explicit sources of staleness, every one of them deliberate:

So the honest statement is the opposite of the claim: this system is eventually consistent by design, and correctly so.

The defence is the one Lesson 2 set out: nothing here is transactional. A rating a day old misleads nobody, because it differs from the current value by less than the noise in the rating itself. Compare a payment system, where a stale balance is a double charge.

What the design does owe, and could easily provide, is read-your-own-writes: a user who posts a review sees it immediately. That is achieved by routing that user's next reads to the leader, or by reading through the write path for a short window. It is the consistency guarantee that actually matters to users, and it is far cheaper than the global one being claimed.

Name the guarantee you provide rather than the one that sounds strongest. "Eventually consistent, with read-your-own-writes for a user's own contributions" is both more accurate and more impressive than "consistent."

Availability and scalability are correctly argued, and share one mechanism

Both arguments are sound and they lean on the same structure, which is worth pointing out.

Availability comes from replication — three copies per tree, failover to a follower, and rebuild from the key-value store. Standard and correct. The partitioning contribution is real but secondary: losing one server loses part of the index rather than all of it.

Scalability comes from the quadtree bounding query cost regardless of density, plus the ability to restructure incrementally as places are added.

Notice what both depend on: the index is small and rebuildable. Twelve gigabytes means replication is cheap, failover is fast, and a lost tree is regenerated in minutes. If the index were a petabyte, neither argument would survive.

That is the underappreciated consequence of Lesson 11's number. Small derived state makes availability easy — you replicate freely, rebuild rather than repair, and never engineer complex recovery.

The performance argument credits the cache and skips the quadtree

"We reduced latency by using caches. We cached all the famous and popular places."

That is true and it is the smaller contributor. Caching popular places avoids database reads for records that would have been fetched anyway. It does not help find which places are nearby, which is the query this whole chapter exists to answer.

The performance story is really three layers, and the design names one:

1. QUADTREE      2-D range scan  ->  ~20 in-memory comparisons   <- the big win
2. IN-MEMORY     no disk on the search path
3. CACHE         avoids DB reads for popular place records       <- the one credited

Lesson 7's naive query scanned millions of rows. The quadtree reduced that to a descent plus a bounded leaf scan. That is the latency answer, and it is worth several orders of magnitude more than the cache.

This is the same failure that building block's evaluation made — listing conventional techniques while omitting the one the design was actually built around. When your evaluation's performance section does not mention your chapter's central mechanism, the evaluation is wrong.

What the design leaves out

Six things worth volunteering

No inverted index for search by name. Lesson 4's search(name_of_place, ...) needs text search, and no component provides it.

No timestamps in the schema. Lesson 5's gap — no review ordering, no recency weighting in ratings, no fraud detection by burst, and the daily rating job cannot be incremental.

No review moderation or fraud detection. Ratings drive ranking, and ranking drives business revenue, which makes fake reviews a direct financial incentive. A rating system with no defence against manipulation is the most consequential omission in the design.

No merge operation on the quadtree. Lesson 13's point — cells only ever split, so the tree deepens permanently until a full rebuild.

Concurrent reads during a split are unaddressed. Copy-on-write solves it, and it is not mentioned.

The third-party dependency for segmentation (Lesson 6) is structural and mostly avoidable, since dividing coordinates is arithmetic.

The fraud one deserves the most emphasis. Every other gap is an engineering detail; that one is an adversarial problem, and adversarial problems do not get better on their own.

The open question SQL or NoSQL

In the previous lesson, we chose a SQL database and a key-value store. How does replacing SQL with NoSQL impact the design? Discuss its impact on scalability and consistency, schema flexibility, and complex queries.

Worth answering, because the honest answer is "less than you would expect."

Scale is not the deciding factor. Lesson 3 established the whole dataset is under 3 TB — comfortably within a single well-provisioned relational instance, let alone a replicated one. The usual argument for NoSQL does not apply.

What relational buys here is the join, and the design uses it: retrieving a place's reviews, a user's history, a place with its photos. Those are exactly the queries the design names as its reason for choosing SQL.

What NoSQL would buy is schema flexibility — places genuinely have heterogeneous attributes, since a restaurant has a menu and a cinema has showtimes, and modelling that relationally means sparse columns or an attributes table.

The pragmatic answer is both, which is what the design already does. Relational for the entities and their relationships; a key-value store for the index and the high-volume lookups. That is not a compromise, it is a correct application of choosing the store for the shape of the data.

When the dataset is small enough that scale is not the constraint, choose the store for its query model and its consistency guarantees — the same reasoning that building block applied to putting billing in a relational store.

Searching by place name rather than coordinates

Real queries are "pizza in NYC" or "coffee in the Mission" — a named region, not a radius from a point. A circle is the wrong shape for a neighbourhood.

Two pieces. Name to polygon is a lookup table populated from public geographic datasets. Polygon to places is the interesting half: testing containment per request is expensive, so precompute the containing regions when a place is created and store them as a list of tags.

The query then collapses from a geometric containment test into an inverted-index term lookup — and because places are written rarely and searched constantly, paying the cost once at write time is exactly the right trade. It is the same move as precomputing the average rating.

Interview signal by level

Next: the whole design under interview conditions.