Mechanical System Design Interview Framework #

A constrained, interview-first companion to the full derivation framework. Its purpose is not completeness. Its purpose is to make design derivation as deterministic, low-judgment, and repeatable as possible in a 45-60 minute system design interview.

Why This Exists #

The full derivation framework is strong on rigor, but still leaves too many decisions implicit for interview use:

• multiple valid decompositions can appear in Step 2
• invariant extraction can expand into secondary concerns too early
• DP grouping is still somewhat subjective
• Q1-Q5 guides mechanism selection, but does not always force one narrow path
• the full 20-step flow is too wide for interview time

This document addresses those issues by imposing:

• a reduced interview scope
• fixed worksheets with closed answer shapes
• a deterministic decision tree
• prioritization rules
• explicit stop conditions

If two competent candidates apply this framework to the same prompt, their designs should be much closer.

Core Principle #

In interviews, derive only what is necessary to preserve business truth on the critical paths.

Everything else is optional until the interviewer asks for it.

The order is fixed:

requirements
  → critical paths
  → primary state
  → write invariants
  → execution context
  → mechanism family
  → required companions
  → read model
  → failure handling
  → scale adjustments

If a step does not change a correctness-critical decision, defer it.

Field Taxonomy #

Every field in this framework must belong to exactly one category:

• Given
  • fixed by the prompt or by explicit user/product constraints
• Chosen
  • true independent architectural commitments
• Classified
  • selected from a closed enum by applying rules to earlier fields
• Derived
  • computed as a predicate or boolean consequence of earlier fields
• Output
  • final artifact row or prose statement produced for auditability

This distinction matters:

• Chosen fields are the real design degrees of freedom
• Classified fields are not free choices
• Derived fields are not choices at all

If a field is mislabeled, the framework becomes less mechanical.

Dependency DAG #

The framework should be read as a DAG, not a linear list of arbitrary questions:

Given:
  requirements
  stated NFRs / constraints

Classified from requirements:
  operation
  priority class

Chosen:
  object decomposition
  ownership boundary
  source-of-truth placement
  execution topology
  read consistency target
  compensation policy

Classified from chosen + given:
  class
  evolution
  scope kind
  invariant tier
  invariant type

Derived:
  primary?
  cross_service_write
  holder_may_crash
  bounded_staleness_allowed
  cross_service_atomicity_required
  exclusive_claim_required
  merge_safe
  guarded_by_current_state
  replaces_current_value
  records_immutable_fact
  single_writer_scope
  partition_routed_single_writer
  same_shape_as_source
  query_crosses_shards
  query_is_geospatial
  read_heavy

Classified from derived predicates:
  write shape
  base mechanism
  read path
  hotspot type

Chosen after mechanism classification:
  required companions

Output:
  source-of-truth table
  failure matrix
  scale response
  worksheet rows

If a later field cannot be traced back to earlier nodes in this DAG, the framework still has a hidden assumption.

Complete Field Graph #

This is the authoritative registry. Every field used by the framework must appear exactly once here.

Rules:

• A Chosen field may depend on Given fields and earlier Chosen fields, but never on later classified outputs.
• A Classified field must be chosen from its enum by rule, not preference.
• A Derived field must be a deterministic consequence of listed parents.
• An Output field may be free text, but it must cite or summarize earlier graph nodes rather than introduce new hidden assumptions.

Archetype Catalog #

Use this catalog during decomposition. An archetype is not a final design. It is a recurring object-and-invariant shape that helps generate candidate objects and likely invariants quickly.

Product Archetypes #

These fit user-facing products and business workflows most naturally.

1. Subject + Append-Only Child #

Shape

• central subject object
• user/system appends child records against that subject
• all valid child writes may coexist

Typical object classes

• subject: entity or process
• child: event, relationship, or authored content object with append-only evolution

Common invariants

• child validity predicate
• child ordering within subject scope
• optional uniqueness of (actor, subject) or request key
• derived child-list view freshness

Usual write shape

• append-only event

Common examples

• Business + Review
• LiveStream + Comment
• Video + Comment
• Ad + ClickEvent
• MetricSeries + Sample

2. Subject + Exclusive Child #

Shape

• many candidate children may be proposed
• at most one active child may hold the subject scope at a time

Typical object classes

• subject: entity or process
• child: relationship, process, or claim object

Common invariants

• at most one active child within subject scope
• stale holder must not continue acting
• claim timeout / release behavior

Usual write shape

• exclusive claim

Common examples

• Seat + SeatHold
• Trip + DriverAssignment
• JobRun + WorkerClaim

3. Subject + Relationship Edge #

Shape

• a subject is connected to another object by an edge with its own lifecycle or uniqueness rule
• the edge is primary state, not just a denormalized join

Typical object classes

• subject: entity or process
• target: entity
• edge: relationship

Common invariants

• uniqueness of the edge key within scope
• edge authorization rules
• edge-list projection freshness

Usual write shapes

• append-only event if edges are immutable
• overwrite current value or guarded state transition if edges may be deactivated/reactivated

Common examples

• Resource + TagAssignment
• User + FollowRelation
• User + Friendship
• User + GroupMembership
• Object + PermissionEdge

4. Subject + Competitive Child #

Shape

• many child proposals may exist
• business truth depends on winner selection against current subject state

Typical object classes

• subject: process
• child: event or proposal record

Common invariants

• conditional acceptance
• total order of accepted children within scope
• uniqueness of logical attempt

Usual write shape

• guarded state transition

Common examples

• Auction + Bid
• Capacity reservation against scarce inventory

5. Subject + Derived Projection #

Shape

• subject is authoritative
• one or more read models are derived for serving

Typical object classes

• subject: entity or process
• projection: projection

Common invariants

• one source of truth
• projection rebuild path
• freshness bound

Usual read path

• materialized view, cache-aside, spatial index, or scatter-gather

Common examples

• Post + SearchIndex
• Business + SearchIndex
• Product + SearchIndex

6. Subject + Aggregate Projection #

Shape

• append-only or observation events feed aggregates
• aggregate is derived, not truth

Typical object classes

• subject: entity
• child: event
• aggregate: projection

Common invariants

• accounting correctness
• dedup of events
• freshness of aggregate

Usual write shape

• child writes are append-only event

Common examples

• Ad + ClickEvent + MetricsAggregate
• MetricSeries + Sample + Rollup
• Business + Review + RatingAggregate

7. Shared Mutable Subject #

Shape

• many writers concurrently edit the same logical subject itself

Typical object classes

• subject: process or shared mutable document object
• child operations may exist, but they target the subject itself

Common invariants

• convergence
• causality / ordering discipline
• no lost concurrent edits

Usual write shape

• commutative merge or specialized transform-based concurrency

Common examples

• Google Docs
• collaborative editors
• multiplayer boards

8. Future Constraint + Claimable Run #

Shape

• work is declared before execution
• time or policy makes work eligible later
• execution is claimable by exactly one worker/dispatcher

Typical object classes

• intent: intent
• run: process

Common invariants

• no early firing
• at most one run per fire instant
• valid run lifecycle

Usual write shapes

• schedule creation: guarded state transition or overwrite current value
• execution claim: exclusive claim

Common examples

• Job scheduler
• recurring task runner

9. Frontier + Claimable Run #

Shape

• executable work items exist in a frontier
• workers claim frontier entries
• completed work may discover more work

Typical object classes

• frontier entry: intent or process
• run: process

Common invariants

• one claim per frontier item at a time
• retry/backoff scheduling
• dedup/canonicalization of discovered work

Usual write shapes

• frontier mutation: overwrite current value or append-only event
• worker claim: exclusive claim

Common examples

• Web crawler
• news aggregation ingest

10. Critical Transactional Process #

Shape

• central process controls business truth
• side effects must be idempotent
• audit/reconciliation trail is required

Typical object classes

• subject: process
• event trail: event
• ledger or accounting records: event

Common invariants

• valid state transitions
• no duplicate external effect
• reconciliation possible from trail

Usual write shapes

• guarded state transition
• sometimes multi-service transaction

Common examples

• Payment
• order/fulfillment
• brokerage order lifecycle

11. Versioned Namespace + Immutable Content Units #

Shape

• logical namespace mutates over time
• content units are immutable and often content-addressed
• synchronization/versioning is first-class

Typical object classes

• namespace entry: entity or process
• content block: event or immutable entity
• revision: event

Common invariants

• version consistency
• dedup by content hash
• sync cursor / replica convergence

Usual write shapes

• namespace update: guarded state transition or overwrite current value
• content ingest: append-only event

Common examples

• Dropbox
• file sync systems

12. Time-Bounded Exclusive Allocation #

Shape

• a resource can be reserved for a bounded interval
• only one active allocation may own a resource-time scope
• expiration, cancellation, and confirmation matter

Typical object classes

• resource: entity
• hold/reservation: process or relationship

Common invariants

• no overlapping active allocation within resource-time scope
• expired holds release cleanly
• confirmation/payment preserves exclusivity

Usual write shapes

• hold: exclusive claim
• confirm/cancel: guarded state transition

Common examples

• restaurant booking
• hotel booking
• calendar slot booking
• locker reservation
• timed inventory holds

Infrastructure Archetypes #

These fit platform, control-plane, coordination, routing, and substrate-heavy systems.

13. Key-Scoped Mutable State #

Shape

• correctness is scoped by key
• state is overwritten, expired, replicated, or evicted by policy

Typical object classes

• key entry: entity
• operational metadata: policy state / projection

Common invariants

• per-key overwrite semantics
• expiry visibility
• eviction correctness within chosen policy scope

Usual write shapes

• overwrite current value
• sometimes exclusive claim for locks/leases

Common examples

• distributed cache
• key-value store
• session store

14. Messaging Log + Consumer Progress #

Shape

• producers append messages to an ordered log or topic
• consumers advance independent progress through that log
• delivery semantics depend on offset/ack handling

Typical object classes

• topic/stream: entity or process
• message: event
• consumer progress / offset: relationship or process

Common invariants

• ordering within partition or conversation scope
• delivery guarantee semantics
• consumer progress monotonicity

Usual write shapes

• publish: append-only event
• claim/ack/progress update: overwrite current value or guarded state transition

Common examples

• message queue
• pub/sub log
• chat conversation stream

15. Control Plane + Data Plane #

Shape

• control plane manages configuration, policy, placement, health, and rollout state
• data plane serves live traffic using that state

Typical object classes

• config/policy objects: entity or intent
• serving/routing state: projection or process
• health observations: event

Common invariants

• one source of truth for control state
• safe propagation from control plane to data plane
• rollback or staged rollout discipline

Usual write shapes

• control updates: overwrite current value or guarded state transition
• health signals: append-only event

Common examples

• load balancer
• feature delivery plane
• mobile OS rollout service
• serverless control plane

16. Optimization / Matching Decision #

Shape

• inputs, constraints, and candidates are collected
• system computes best assignment, compatibility, or ranking decision
• result is a decision object or projection

Typical object classes

• candidate set: collection of entities
• constraint/compatibility state: entity or relationship
• assignment/decision: process, relationship, or projection

Common invariants

• assignment respects constraints
• decision is recomputable from authoritative inputs
• stale inputs are bounded for acceptable decision quality

Usual write shapes

• input events: append-only event
• decision output: overwrite current value or guarded state transition

Common examples

• workspace assignment
• route-sharing compatibility
• some recommendation or matching systems

17. Market / Order Book Process #

Shape

• participants submit orders, bids, offers, or quotes
• matching/ranking/selection changes market truth
• event trail and derived positions or books are critical

Typical object classes

• order/book subject: process
• submission/fill/execution: event
• position/portfolio/book view: projection

Common invariants

• valid lifecycle transitions
• ordering within market scope
• no duplicate execution
• reconciliation from event trail

Usual write shapes

• order lifecycle: guarded state transition
• executions/fills: append-only event

Common examples

• stock trading
• brokerage order systems
• EC2 spot bidding / allocation

18. Sequence / Identifier Generation #

Shape

• generator instances produce unique identifiers from local mutable state plus deterministic composition
• correctness is dominated by uniqueness and ordering/monotonicity within chosen scope

Typical object classes

• generator state: entity
• generator lease/worker identity: relationship or process

Common invariants

• no duplicate IDs within global scope
• monotonicity within configured generator scope
• generator identity uniqueness

Usual write shapes

• overwrite current value
• sometimes exclusive claim for worker-id allocation

Common examples

• Snowflake-style ID generator

19. Coordination / Consensus Metadata Store #

Shape

• small authoritative metadata store used for coordination, membership, config, and leader election
• correctness depends on ordered metadata mutation and watch/notification propagation

Typical object classes

• metadata node: entity
• lease/leadership state: process or relationship

Common invariants

• one authoritative view of coordination state
• valid leader/lock ownership
• monotonic metadata versioning

Usual write shapes

• guarded state transition
• exclusive claim
• overwrite current value

Common examples

• ZooKeeper-like systems

20. Origin Projection + Edge Delivery Plane #

Shape

• origin content is authoritative
• edge caches and routing layers project that content close to users
• invalidation, freshness, and policy propagation dominate

Typical object classes

• origin object: entity
• edge cache entry: projection
• routing/policy config: entity or intent

Common invariants

• one origin truth
• bounded cache staleness
• safe invalidation / rollout of edge policy

Usual write shapes

• origin mutation: inherited from origin system
• edge cache state: overwrite current value
• policy rollout: guarded state transition

Common examples

• CDN

How To Use The Catalog #

1. Use normalized requirements to identify whether the prompt matches one dominant archetype or a composition.
2. Use the archetype to generate candidate objects and likely invariant types.
3. Do not stop at archetype recognition. Continue with the field graph and step-by-step derivation.

First Branch #

Before picking a detailed archetype, ask:

• is this primarily a user-facing product/workflow system?
• or is this primarily an infrastructure/platform/control substrate system?

Choose the catalog section first. This improves fit and reduces false analogy.

Common System Mappings #

Interview Mode #

Hard Scope #

Default interview output is 9 steps:

1. Requirement normalization
2. Critical path selection
3. Primary state extraction
4. Invariant extraction
5. Execution context declaration
6. Deterministic mechanism selection
7. Read-model derivation
8. Failure handling
9. Scale adjustments

Do not discuss:

• exact products
• deployment topology
• observability
• runbooks
• cost
• evolution

unless the interviewer asks.

Time Budget #

Use this split for a 45-60 minute interview:

Stop Rule #

You are done with the baseline design when all of these are true:

• every correctness-critical write path has an invariant
• execution context assumptions are explicit
• every such invariant has a mechanism family
• every mechanism family has required companion mechanisms
• every important read has a declared source of truth
• every retry/crash/duplicate case on critical writes has an answer

If all six are satisfied, stop expanding unless prompted.

Step 1 — Requirement Normalization #

Goal #

Rewrite product language into state operations. Use only this worksheet.

Field Types #

This step contains one classified field:

• Operation

This step contains one classified field:

• State interaction kind

This step contains one derived field:

• State reference ID

This step contains one output field:

• State target label

This step contains one output field:

• Critical now?

Worksheet #

Allowed Operation Values #

Every requirement must map to exactly one of:

• conditional write
• append event
• overwrite state
• state transition
• read source
• read projection
• async deliver
• async process

If a requirement seems to need two operations, split it into two rows.

Derived State reference ID Rule #

Assign state reference IDs within each normalized requirement row:

• first referenced state → S1
• second referenced state → S2
• third referenced state → S3

Allowed State interaction kind Values #

Classify each referenced state as exactly one:

• create target
• update target
• delete target
• read source target
• read projection target
• async side-effect target
• hidden write target

State Cell Format #

In later tables, render State touched as one nested cell in this order:

State reference ID
State interaction kind
State target label

Completion Rule #

No requirement may remain in UI language.

Step 2 — Critical Path Selection #

Goal #

Force prioritization. Most interview mistakes come from designing everything at once.

Field Types #

This step contains one classified field:

• Priority class

Classification #

Label each normalized row as exactly one:

• C1: correctness-critical write
• C2: supporting write
• R1: important read
• R2: optional read
• N1: notification or background path

Decision Rule #

Work in this order only:

1. all C1
2. all R1
3. the minimum N1 needed to keep the story coherent
4. everything else only if asked

Mechanical Test for C1 #

A path is C1 if stale or incorrect execution changes business truth:

• double charge
• double booking
• duplicate match
• accepting an invalid bid
• losing committed user data

A path is not C1 if failure causes only lag or degraded UX:

• stale leaderboard
• delayed notification
• cold cache miss
• slow search indexing

Output Artifact #

Derived Path ID Rule #

Assign path IDs by normalized requirement order:

• first retained path → P1
• second retained path → P2
• third retained path → P3

Allowed Path kind Values #

Classify each retained path as exactly one:

• write path
• read path
• background path

Derive using this rule:

• C1 or C2 → write path
• R1 or R2 → read path
• N1 → background path

Path Cell Format #

In later tables, render Path as one nested cell in this order:

Path ID
Path kind
Path label

Example:

P1
write path
Place bid

Step 3 — Primary State Extraction #

Goal #

Identify only the primary state needed to support C1 and R1.

Field Types #

This step contains one output field:

• Candidate object label

This step contains seven classified fields:

• Candidate source
• Candidate needed for C1/R1?
• Candidate decomposition action
• Class
• Owner
• Evolution
• Scope kind

This step contains one derived field:

• Primary?

Candidate Generation Rule #

Do not begin with an unstructured object list.

Generate candidate rows mechanically from the normalized requirements. For each requirement row, add one candidate row for every applicable source:

• direct noun
• hidden write target
• lifecycle object
• future constraint
• relationship edge
• derived read model

This converts brainstorming into structured rows. Only the candidate label remains free text.

Allowed Candidate source Values #

Every candidate must be tagged as exactly one:

• direct noun
• hidden write target
• lifecycle object
• future constraint
• relationship edge
• derived read model

Allowed Candidate needed for C1/R1? Values #

Use exactly one:

• Yes
• No

Interview baseline keeps only candidates marked Yes.

Allowed Candidate decomposition action Values #

Use exactly one:

• keep as candidate
• split candidate
• reject as UI artifact

If you choose split candidate, create replacement candidate rows immediately.

Allowed Class Values #

Every candidate object must be exactly one:

• entity
• event
• process
• intent
• relationship
• projection

Allowed Owner Values #

Use exactly one:

• user
• client
• service
• worker
• scheduler
• pipeline
• derived

If more than one seems necessary, the object is probably underspecified or should be split.

Allowed Evolution Values #

Use exactly one:

• append-only
• overwrite
• state machine
• merge

These values are closed because Step 5 depends on them. Do not invent new evolution labels.

Allowed Scope kind Values #

Use exactly one:

• instance
• relation
• time
• region
• collection
• global

These are conceptual scopes, not storage layouts.

The concrete scope value may still be free text, for example:

• instance: job_id
• relation: (user_a, user_b)
• time: fire_time
• region: rider pickup zone
• collection: all bids for auction_id

Physical interpretations are deferred to later steps. For example:

• instance may later map to a primary key
• relation may later map to a composite key
• time may later map to an index or bucket
• region may later map to a spatial partition
• collection may later map to a partition key or range scan

Deterministic Validity Test #

A candidate is primary state only if all answers are Yes:

If any answer is No, do one of:

• split the object
• downgrade it to projection
• discard it as UI artifact

Derived Primary? Rule #

Primary? is not an independent design choice.

Set:

• Primary? = Yes if the candidate passes the full validity test
• Primary? = No otherwise

The worksheet keeps this as an explicit output field only so the classification is auditable.

Forced Output Shape #

Tie-Break Rule #

If two decompositions seem valid, pick the one with fewer primary objects.

Interview mode prefers under-modeling over speculative modeling.

Step 4 — Invariant Extraction #

Goal #

Extract only invariants that directly constrain C1 writes or define truth for R1 reads.

Field Types #

This step contains three classified fields:

• Tier
• Type
• Invariant template

Invariant Tiers #

Every invariant must be labeled exactly one:

• HARD: violation changes business truth
• SOFT: violation causes lag, staleness, or poor UX

In interview baseline, derive all HARD invariants first. Mention SOFT invariants only after the baseline is closed.

Allowed Invariant Types #

Every invariant must be exactly one:

• eligibility
• uniqueness
• ordering
• accounting
• authorization
• freshness

Allowed Invariant template Values #

Derive exactly one from Type:

• eligibility → eligibility template
• uniqueness → uniqueness template
• ordering → ordering template
• accounting → accounting template
• authorization → authorization template
• freshness → freshness template

Invariant Template Grammar #

Do not write unconstrained prose. The invariant statement must follow the template implied by Type.

eligibility template #

Action <action> is valid only if <predicate> holds on <scope> at decision time.

uniqueness template #

Key <key> maps to at most one logical outcome <outcome> within <scope>.

ordering template #

Instances <instances> are ordered by <relation> within <scope>.

accounting template #

Aggregate <aggregate> equals <function> over <source set> within <scope>.

authorization template #

Actor <actor> may perform <operation> on <object> only if <predicate> holds.

freshness template #

Read model <read model> reflects <source> within <bound>.

Worksheet #

Rewrite Rule #

Bad:

• system should be correct
• bids should not conflict

Good:

• Action accept_bid is valid only if auction.status = OPEN AND bid.amount > auction.current_highest holds on auction_id at decision time.
• Key request_id maps to at most one logical outcome bid acceptance result within auction_id.

Completion Rule #

For each C1 path, there must be at least:

• one business invariant
• one duplicate/retry invariant if the operation is non-idempotent

Step 5 — Execution Context Declaration #

Goal #

Make the non-functional and execution assumptions explicit before mechanism selection.

Mechanism derivation is not based on functional requirements alone. It depends on:

• failure model
• service boundaries
• consistency expectations
• compensation semantics

If these are not declared first, Step 6 will smuggle NFR assumptions in as if they were derived from FRs.

Field Types #

This step contains five chosen fields:

• Topology
• Write coordination scope
• Read consistency target
• Holder model
• Compensation acceptable?

This step contains three derived predicates:

• holder_may_crash
• cross_service_write
• bounded_staleness_allowed

Allowed Topology Values #

Use exactly one:

• single process
• single service distributed
• multi-service

Allowed Write coordination scope Values #

Use exactly one:

• local only
• per object scope
• cross service

Allowed Read consistency target Values #

Use exactly one:

• strong only
• bounded stale allowed

Allowed Holder model Values #

Use exactly one:

• none
• thread
• process
• worker
• node

Allowed Compensation acceptable? Values #

Use exactly one:

• Yes
• No

Derived Predicate Rules #

Set holder_may_crash = true iff:

• Holder model is process, worker, or node

Set cross_service_write = true iff:

• Topology = multi-service
• and the path touches primary objects with different owners

Set bounded_staleness_allowed = true iff:

• Read consistency target = bounded stale allowed

Forced Output Shape #

Completion Rule #

No mechanism may be selected before this table is filled.

Step 6 — Deterministic Mechanism Selection #

Goal #

Replace open-ended architecture discussion with a closed decision procedure.

Field Types #

This step contains two classified fields:

• Write shape
• Base mechanism

This step contains one chosen field:

• Required companions

Part A: Pick the Write Shape #

Every C1 path must be classified as exactly one:

• append-only event
• overwrite current value
• guarded state transition
• exclusive claim
• commutative merge
• multi-service transaction

Do not invent additional write-shape labels in interview mode.

Derivation Rule For Write shape #

Write shape is not a free design choice. It is a classification derived from the path semantics.

First derive these predicates from earlier steps:

• cross_service_atomicity_required
• exclusive_claim_required
• merge_safe
• guarded_by_current_state
• replaces_current_value
• records_immutable_fact

Derived Predicate Rules #

Set cross_service_atomicity_required = true iff all are true:

• the invariant is HARD
• the path touches more than one primary object
• those primary objects have different owners
• the invariant must hold synchronously at write time
• compensation is not acceptable

Set exclusive_claim_required = true iff:

• correctness requires exactly one active claimer, holder, or executor for a bounded period

Set merge_safe = true iff:

• concurrent writes may all succeed
• the merge law is commutative and associative
• no winner-loser decision is required

Set guarded_by_current_state = true iff:

• the write is valid only when a predicate over current authoritative state holds

Set replaces_current_value = true iff:

• the write replaces the current value of a stable object without requiring winner-loser conflict resolution beyond ordinary overwrite semantics

Set records_immutable_fact = true iff:

• the write appends a new immutable record and does not invalidate peer writes in the same correctness scope

Classification Rule #

Classify using this rule in order:

1. If cross_service_atomicity_required = true, classify as multi-service transaction.
2. Else if exclusive_claim_required = true, classify as exclusive claim.
3. Else if merge_safe = true, classify as commutative merge.
4. Else if guarded_by_current_state = true, classify as guarded state transition.
5. Else if replaces_current_value = true, classify as overwrite current value.
6. Else if records_immutable_fact = true, classify as append-only event.
7. Else the path has been modeled incorrectly and must be normalized again.

Diagnostic Mapping #

Use this mapping to justify the classification:

Allowed Base mechanism Values #

Use exactly one of:

• single writer
• single writer per partition
• CAS on version
• CAS on (state, version)
• pessimistic lock
• lease
• CRDT
• append log
• Saga
• 2PC

If none fit, the object modeling is probably wrong.

Derivation Rule For Base mechanism #

Base mechanism is not a free design choice. It is classified from:

• Write shape
• ownership shape
• evolution
• whether the holder may crash
• whether service boundaries are crossed
• whether compensation is acceptable

First derive these predicates from earlier steps:

• single_writer_scope
• partition_routed_single_writer
• holder_may_crash
• cross_service_write
• compensation_acceptable

Derived Predicate Rules For Base mechanism #

Set single_writer_scope = true iff:

• exactly one writer owns the full correctness scope for the path

Set partition_routed_single_writer = true iff:

• one writer owns each partitioned correctness scope
• different scopes may be processed independently in parallel

Set holder_may_crash = true iff:

• Step 5 derives holder_may_crash = true

Set cross_service_write = true iff:

• Step 5 derives cross_service_write = true

Set compensation_acceptable = true iff:

• Compensation acceptable? = Yes

Classification Rule For Base mechanism #

Classify using this rule in order:

1. If Write shape = multi-service transaction and compensation_acceptable = true, classify as Saga.
2. Else if Write shape = multi-service transaction and compensation_acceptable = false, classify as 2PC.
3. Else if single_writer_scope = true, classify as single writer.
4. Else if partition_routed_single_writer = true, classify as single writer per partition.
5. Else if Write shape = commutative merge, classify as CRDT.
6. Else if Write shape = exclusive claim and holder_may_crash = true, classify as lease.
7. Else if Write shape = exclusive claim and holder_may_crash = false, classify as pessimistic lock.
8. Else if Write shape = guarded state transition and Evolution = state machine, classify as CAS on (state, version).
9. Else if Write shape = overwrite current value and Evolution = overwrite, classify as CAS on version.
10. Else if Write shape = append-only event, classify as append log.
11. Else the path has been modeled incorrectly and must be normalized again.

Diagnostic Mapping For Base mechanism #

Allowed Required companions Values #

This field is a set chosen only from:

• idempotency key
• dedup by event_id
• fencing token
• outbox
• CDC
• idempotent consumer
• compensation
• sequence authority
• heartbeat

Use no free-form companion labels in interview mode.

Part C: Mandatory Companion Rules #

After selecting the base mechanism, attach companions mechanically:

Part D: Read Path Derivation #

Read path is not a free design choice. It is a classified field derived from:

• source-of-truth placement
• read consistency target
• read/write skew
• whether read shape matches source shape
• whether the query crosses partitions
• whether the query is geospatial

First derive these predicates:

• same_shape_as_source
• read_heavy
• query_crosses_shards
• query_is_geospatial
• staleness_allowed

Derived Predicate Rules For Read path #

Set same_shape_as_source = true iff:

• the user-facing read can be served directly from the authoritative write model without reshaping or precomputation

Set read_heavy = true iff:

• stated NFRs or the prompt imply read load dominates write load on this path

Set query_crosses_shards = true iff:

• the read requires fan-out across more than one correctness scope or partition

Set query_is_geospatial = true iff:

• the read asks for proximity, containment, radius, or location-based lookup

Set staleness_allowed = true iff:

• Step 5 derives bounded_staleness_allowed = true

Allowed Read path Values #

Classify each R1 read as exactly one:

• read source directly
• cache-aside
• materialized view
• denormalized row
• spatial index
• scatter-gather

Do not attach multiple read paths to one baseline R1 requirement. Pick the first sufficient one.

Classification Rule For Read path #

1. If query_is_geospatial = true, classify as spatial index.
2. Else if query_crosses_shards = true, classify as scatter-gather.
3. Else if same_shape_as_source = false, classify as materialized view.
4. Else if read_heavy = true and staleness_allowed = true, classify as cache-aside.
5. Else if same_shape_as_source = true, classify as read source directly.
6. Else if a join-heavy hot read still matches one logical row shape after precomputation, classify as denormalized row.
7. Else the read has been modeled incorrectly and must be restated.

Output Artifact #

Step 7 — Source of Truth and Read Model #

Goal #

Prevent dual truth and make read design explicit but bounded.

Field Types #

This step contains one classified field:

• Read path

This step contains one classified field:

• Concept kind

This step contains one derived field:

• Staleness allowed?

This step contains one derived field:

• Concept ID

Derived Concept ID Rule #

Assign concept IDs by source-of-truth table order:

• first concept row → C1
• second concept row → C2
• third concept row → C3

Allowed Concept kind Values #

Classify each concept as exactly one:

• source concept
• projection concept
• aggregate concept
• relationship concept
• status concept

Concept Cell Format #

In later tables, render Concept as one nested cell in this order:

Concept ID
Concept kind
Concept label

Example:

C1
projection concept
Highest bid

Forced Table #

Derived Staleness allowed? Rule #

Set:

• Staleness allowed? = Yes if Step 5 derives bounded_staleness_allowed = true
• Staleness allowed? = No otherwise

Rules #

• Every concept gets exactly one source of truth.
• A cache is never truth.
• A projection must be rebuildable from primary state.
• If you cannot name the rebuild path, you do not yet have a valid projection.

Interview Shortcut #

If asked for read scaling, say:

1. truth remains in primary state
2. read model is derived
3. rebuild comes from source log or source table

That is enough unless pushed further.

Step 8 — Failure Handling #

Goal #

Cover only the failure cases that can corrupt truth on C1 paths.

Field Types #

This step contains five output fields:

• Retry
• Competing writers
• Crash after commit
• Publish failure
• Stale holder

Mandatory Failure Matrix #

For every C1 path, answer these five rows only:

Mechanical Output #

Completion Rule #

If any C1 path lacks one of the five answers, the design is incomplete.

Step 9 — Scale Adjustments #

Goal #

Apply scaling only after correctness is closed.

Field Types #

This step contains one classified field:

• Hotspot type

Allowed Scale Types #

Each hotspot must be exactly one:

• read hotspot
• write throughput hotspot
• contention hotspot
• fan-out hotspot
• storage growth hotspot

Deterministic Response Table #

Rule #

Never change the source-of-truth mechanism to solve a read problem.

Example:

• stale auction read problem → cache/projection fix
• hot auction CAS storm → single-writer queue for that auction_id

Full Interview Worksheet #

Use this exact sequence during an interview.

Sheet A — Normalize #

Sheet B — Primary State #

Sheet C — Hard Invariants #

Sheet D — Execution Context #

Sheet E — Mechanism Selection #

Sheet F — Read Model #

Sheet G — Failure Matrix #

Sheet H — Scale #

Interview Script #

Use this verbal sequence. It is intentionally repetitive.

1. “I’ll first normalize the requirements into writes, reads, and background paths.”
2. “I’ll prioritize correctness-critical writes before designing projections.”
3. “I’ll identify the smallest primary state needed to preserve truth.”
4. “For each critical write, I’ll state the hard invariants.”
5. “Then I’ll declare the execution context that constrains valid mechanisms.”
6. “Then I’ll select the mechanism mechanically from the derived predicates.”
7. “Then I’ll derive the read model, keeping one source of truth.”
8. “Then I’ll cover retries, duplicates, crashes, and scaling.”

This script signals control and prevents premature deep dives.

Worked Example: Auction #

A. Normalize #

B. Primary State #

C. Hard Invariants #

D. Execution Context #

E. Mechanism Selection #

F. Read Model #

G. Failure Matrix #

H. Scale #

This is enough for a correct interview baseline.

Anti-Expansion Rules #

These rules exist to stop over-design.

• Do not introduce Kafka unless you already have an async propagation need.
• Do not introduce Redis until you have either a read hotspot, lease requirement, or spatial index requirement.
• Do not introduce microservices unless two paths have clearly different scaling or correctness requirements.
• Do not discuss exact shard counts unless the interviewer asks for capacity planning.
• Do not solve search, analytics, and notifications before closing the core write path.

What Makes This More Foolproof #

Compared with the full derivation framework, this version is stricter in six ways:

1. It limits the design surface to interview-critical outputs.
2. It replaces open-ended prose with forced worksheets.
3. It separates HARD invariants from SOFT ones.
4. It makes execution-context assumptions explicit before mechanism selection.
5. It uses a deterministic mechanism decision tree instead of broad guided exploration.
6. It defines a stop condition so candidates do not drift into optional architecture.

The goal is not maximal completeness. The goal is minimal ambiguity.

Compact Checklist #

1. Normalize every requirement into one operation row.
2. Mark every row C1, C2, R1, R2, or N1.
3. Keep only the primary state required by C1 and R1.
4. Write only HARD invariants first.
5. Declare execution context explicitly.
6. Classify each C1 write as one of the write-shape enum names.
7. Apply the predicate-based classification and pick one base mechanism.
8. Attach mandatory companion mechanisms mechanically.
9. Give every concept one source of truth.
10. Give every C1 path answers for retry, concurrency, crash, publish, stale-holder.
11. Apply scale fixes only after correctness is closed.
12. Stop when baseline closure conditions are met.

If you cannot fill one worksheet row, your design is not yet mechanical enough.