All Posts
Read production engineering posts as evidence with a scope and date.
What, why, when and how
What is it?
This index is a guide to reading scoped first-party engineering accounts and transferring their mechanisms into original exercises.
Why is it needed?
Without source boundaries, historical measurements and inferred components can become unsupported company claims.
When should I use it?
Use it before repeating a production fact or treating a company article as a complete current architecture.
When should I choose something else?
Do not turn your own model test or workload assumption into evidence about an undisclosed production implementation.
How do I use it?
Record URL, date, section, supported claim and unknowns; label inference, assumptions and proposed designs separately.
Can you show a concrete example?
Assuming 12,000 arrivals/s, 8,000 completions/s and 120,000 free staging slots gives a 30-second exhaustion window. This is our worksheet, not a claim about Slack.
Read the diagram
First-party claim: keep its date and boundary; Unknown policy: name what the source does not disclose; Exercise assumption and tested proposal are separate
Follow the detailed diagrams below to trace the additional state changes and failure cases behind these answers.
Outcome: read a company engineering post as scoped evidence, extract a reusable mechanism and keep your interview reconstruction distinguishable from the published account.
Production case studies help explain why a team selected a design under particular constraints. They seldom document every component, current scale, or every service in the company. This index links six curriculum case pages and a source ledger. Publication dates and short source scopes below were checked against the first-party articles for this editorial batch. That source check is not a fresh correctness signoff of all six case-study lessons; those lessons remain in the later review batch.
Keep four kinds of statements distinct
| Statement type | Example wording | Evidence required |
|---|---|---|
| Published fact | “The cited post describes a reservation migration” | Specific first-party article and its publication context |
| Inference | “This boundary may require a stale-owner check” | Reasoning that connects the described mechanism to the failure |
| Exercise assumption | “Assume 12,000 arrivals/s for this worksheet” | Explicit declaration that the number is our input |
| Proposed design | “Our queue would reject admission above this bound” | A stated product contract, enforceable mechanism and test |
Do not turn an inference into a quoted company fact. Do not present a historical rate as today's traffic. A mechanism can remain useful even when a publication is old, but its configuration and operational context must be kept with it.
First-party source ledger
| Curriculum case | First-party account and date | What this source describes | What we do not infer from it |
|---|---|---|---|
| Shopify Inventory Reservations | Reservation migration, 2026-05-12 | Moving reservation logic into MySQL, bounded unit pools and connection visibility | An arbitrary provider payment is part of one database transaction |
| Discord Message Storage | Message storage, 2023-03-06 | The reported storage migration and request-handling changes | A complete current topology for every Discord system |
| Slack Job Queue | Queue scaling, 2017-12-06; page updated 2020-06-25 | A historical queue redesign after capacity-related failure | Current traffic or an exactly-once promise for arbitrary job effects |
| Figma Multiplayer | Multiplayer technology, 2019-10-16 | The design-tool collaboration model discussed by the author | Every text-editing system uses the same conflict semantics |
| Spotify Data Lake | Online point queries, 2026-07-27 | External key-to-file/row access for data-lake point queries | A complete platform architecture or current end-to-end access-control policy |
| Meta ZGateway | ZippyDB proxy, 2026-09-03 | A shared proxy boundary for connection and request management | One reported model or mechanism describes every Meta backend |
Source titles above are shortened link labels. Follow the first-party account for its full wording and explanation. Our diagrams are original teaching drawings; company figures and prose are not copied into this lesson.
Keep the two Spotify readings separate
The 2024 data-platform overview, published 2024-04-02, describes the broader organization and evolution of data-platform responsibilities. The 2026 point-query account linked in the ledger addresses a specific access method for existing Parquet data. Their dates and system boundaries differ.
It is useful to ask how a point-query path might interact with a larger platform. That is an inference or a new design question, not permission to join the two posts into one fully documented current topology. In our curriculum's point-query exercise, an immutable file-generation reference is a proposed correctness boundary; verify each company claim against the particular passage that supports it.
Build a claim ledger while reading
For a claim worth repeating, record the source URL, publication/update date, relevant section, short paraphrase, system boundary, and what remains unknown. If the article reports a metric, preserve the measured operation, units and context. Avoid turning a latency from one read path into a system-wide SLO.
| Worksheet field | Original example entry |
|---|---|
| Source boundary | The article's named queue subsystem |
| Published mechanism | Summarize only the mechanism actually described |
| Unknown | Current recovery objective and per-tenant scheduling policy |
| Exercise assumption | 12,000 arrivals/s, 8,000 completions/s, 120,000 free staging slots |
| Proposed test | Hold the declared rates and measure admission behavior as free staging runs out |
Read the diagram
Assume arrivals 12,000/s; completions 8,000/s; Backlog grows 4,000/s; 120,000 free staging slots / 4,000/s = 30 s; This is our model, not a current company metric
Under those exercise inputs, backlog grows by 4,000 jobs/s and the free staging slots are exhausted after 30 seconds. The result is a statement about the worksheet. It does not prove those are the company's rates, that every job occupies the same bytes, or that the published system has that admission policy. If the staging limit is in bytes, include record sizes and overhead instead of silently counting jobs.
Transfer one mechanism and test its limits
After reading the queue case, independently design a reminder service. Define durable intent, due time, tenant fairness, attempt identity, cancellation and the provider's uncertain response. You may learn from the idea of separating durable ingress from bounded executable work. Still show which source of truth owns each reminder and what happens when callbacks duplicate.
After reading collaboration, independently design a shared text document. Ask whether updates are object properties, whole-file versions or character operations. A rule that merges independent shape properties is not automatically a text-editing convergence algorithm. Preserve operation identity and replay, but select a conflict model that satisfies the new product.
Check a migration proposal against its authority
A shadow comparison can reveal mismatches while the original system remains authoritative. It does not by itself make a dual-write handoff atomic or supply safe rollback. For your proposed migration, define how writes are ordered, what state is compared, which generation owns decisions at cutover, and how the old path stays compatible. If the source explicitly describes a different rollout, attribute it; otherwise label your protocol as a proposal.
Prediction and attribution exercises
Question: An old article says the system processed a large daily volume. Can you place that number on a current architecture diagram?
Show answer and explanation
Answer: Label it with the publication's date, units and measured boundary if the comparison needs it. Verify newer evidence before claiming it is current. A daily total does not establish a peak rate, per-tenant skew or failure capacity.
Question: Your modeled rollback test passes. Does that validate the company's actual rollback protocol?
Show answer and explanation
Answer: It validates the modeled conditions you tested. It cannot establish an undisclosed production protocol. Keep the test result with the proposed design and keep published claims with their source.
Continue to one scoped case
Choose the case whose mechanism addresses a current learning question. Record two supported claims, one important unknown and one new failure you would test. The result should be an attributable reading note and an independently defensible design, not a guessed corporate map.