System-design drill content: 8 errors including DDL that won't run and capacity math that's off
Ran the same generate-then-adversarially-verify accuracy pass over the system-design and DB content (sdtopics.ts, lld.ts, dbperf.ts). Eight confirmed errors: a CREATE TABLE/INDEX pair that fails to run, two wrong read:write ratios spoken verbatim, a DynamoDB-tagged Postgres schema, and several cases where the prose claimed the code handled an edge it didn't.
After the earlier audits, the owner asked for the same accuracy treatment on the system-design content, since "relational DB performance at scale" is an explicit grade on the JD and the pairing rounds probe trade-offs hard. The files: lib/sdtopics.ts (910 lines), lib/lld.ts (749), lib/dbperf.ts (395). Chunked review, each flagged error independently confirmed by a second agent that re-derived any arithmetic by hand. Eight survived.
The worst was a reconciliation-system data model whose mismatch table created an index on created_at — a column it never declared. That DDL doesn't run; Postgres throws column "created_at" does not exist (42703). And the ko text leaned on exactly that index for the review-queue query, so the whole design hinged on a table that can't be created. The table also had no primary key while its sibling did. Fixed by adding the column and a BIGSERIAL PRIMARY KEY.
Two errors were in numbers the owner says out loud. Listings-search claimed read:write ≈ 100:1, but the card's own figures were 5,000 avg search QPS over ~200 writes/s — that's 25:1, and the spoken line said "about a hundred-to-one." Activity-feed said "600 read QPS versus 60 write QPS — roughly 20 to 1," but 600/60 is 10. A senior does that division in their head; both are now corrected everywhere (ko, code, and the verbatim sayEn).
A pricing card was tagged DynamoDB but showed Postgres DDL — TIMESTAMPTZ, JSONB, PRIMARY KEY (home_id, created_at) — none of which is how you declare a DynamoDB table. Its sibling card had even argued the QPS was too low to justify NoSQL. Unified to Postgres.
The rest were code-versus-claim drift in the LLD cards. The LRU put() step shown for study omitted the if (capacity <= 0) return; guard, yet the edge-case card asserted "the code above already handles this" — without the guard, a zero-capacity cache tries to evict the head sentinel and breaks. (The polished fullCode had the guard; the step you actually read didn't.) The elevator's addStop() had no branch for a request to the current floor, so it was silently dropped while the spoken line promised "opens the door on arrival." And the notification card claimed ConcurrentHashMap made the service "multithread safe" — it only makes the maps safe; notify() still needs an idempotency key to avoid duplicate sends on concurrent retries.
Only dbperf.ts came out nearly clean: one card's step-4 query plan had dropped the Sort/Limit nodes (a Bitmap Heap Scan can't return rows in created_at order), which also contradicted the very next step's "the plan still has a Sort." Restored the wrapper.
The pattern across all three audits this session: an architecture review is not a content review, capacity math needs re-derivation rather than a nod, and "the code already handles X" claims must be checked against the exact snippet shown — not the cleaned-up version elsewhere in the file.