Section 12: The Index Narrows, the Owner Decides - Final Summary & Candidate Scorecard

Executive Summary: This closing section turns the module into something you can score yourself against. We replay the interview arc and name the signal each phase was really recording, then lay out the 100-point scorecard: five dimensions, weighted so that finding the permission problem and defending the read path count for more than drawing boxes. Score bands map your total to a readiness level and a remedy, and a closing catalog shows six disguises this question wears in real loops.

Here is the uncomfortable truth about the hour you just spent. The table you designed in Section 5 (one assignment row, a forward key, two reverse indexes, about 3.2 TB across 64 shards) was the part any competent engineer could produce. The interviewer was scoring something else. Did you notice, before drawing a single box, that the tagging service owns the tags but not the content or the permissions? Did your arithmetic decide anything? When Meridian's frontend tag showed up with 1.2M assignments, did you have a mechanism, or just an adjective? You cannot reliably earn points you cannot name, so this section names them.

The Arc, Replayed as Signal

Walk the left column and listen for what the room heard.

Clarification. Six questions, but one carried the interview: "Should clicking a tag show items I can't see?" The answer was "absolutely not," and that turned a join table into a permission problem across three systems you don't own. Dana's checkout-outage tag landed on four items in three products, one of them the restricted PAY-4315. Asking it before sketching was the first strong signal of the hour.

Estimation. The numbers mattered for what they ruled out: about 1,400 writes/s at peak (about 22/s per shard) and about 3.2 TB of primary data, so nothing needs exotic storage. The forward read at about 20,800/s is the hot path, and a 90% hit rate on a cache of tag ids brings it down to about 2,080/s at the primaries. Tag pages run at only about 70/s, but each is expensive and permission-bound. Skew, not volume, is the real scale problem, and storage and blast radius, not throughput, set the shard count.

API and data model. Per-tag PUT and DELETE with set semantics, so two editors can't erase each other's tags the way a whole-list PUT would. Tags keyed by a surrogate tag_id, so a rename is O(1) instead of rewriting every row. Content refs that use immutable ids, because PAY-4312 can become OPS-118 after a move. And the assignment, count upsert and outbox row in one single-shard transaction, which is why Postgres sharded by tenant beat two DynamoDB tables kept in sync by dual writes. The flip trigger is a tenant outgrowing its shard at about 1 TB or 5,000 writes/s.

Architecture. What you left out scored as highly as what you drew. You drew no search engine, no graph database, no ACL copy and no global index, and each absence came with the trigger that would flip it.

Deep dives. Version-checked content events, each carrying the item's full state, kept the index true while content moved, got trashed and got locked down, with hydration as the safety net for every item shown. The read path is where the module earned its name. The index narrows by tenant and accessible containers, and the owning product decides on every item it hydrates. Dana sees 4 items, Priya 3 and Sam 2, and Dana's count of 3 is the documented lower bound Section 8 derives.

Gauntlet and growth. When Bitbucket's hydration went down, you returned a partial: true page rather than a single unhydrated ref. You deleted Meridian's frontend tag in O(1) and purged it in about 20 minutes on the bulk lane. Every Section 11 feature went in as a new table, consumer or column, never a rewrite.

A strong interview often ends with a question like this:

Interviewer: "If I could write one sentence about your design in my notes, what should it be?"
You: "The tag table is the easy part. It's 3.2 TB and 1,400 writes a second. The hard part is that every tag page is a query over content three other systems guard, so the index narrows and the owner decides."

Key Insight: Read the right-hand column again and notice that none of those signals is about knowing exotic technology. Each comes from Postgres, Redis, Kafka and a call to someone else's permission API, used in proportion to a measured problem, with the humility to let the content owner have the last word.