Mechanical Infrastructure System Design Interview Companion #

A focused companion to the Mechanical System Design Interview Framework for infrastructure and platform interviews. The core field graph and mechanism derivation stay shared. This document narrows the entry point, archetypes, technology silhouettes, and presentation style for infra-heavy prompts.

Why This Exists #

Infrastructure interviews usually emphasize:

• authoritative state instead of user workflow
• control plane vs data plane boundaries
• ordering, coordination, and replication scopes
• failure semantics before product projections

The shared interview framework already covers these, but product and infra prompts benefit from different first instincts. This companion provides that infra-first adaptation without duplicating the full field graph.

How To Use This Companion #

1. Start with the shared framework for:
   • field taxonomy
   • dependency DAG
   • complete field graph
   • step-by-step worksheet
   • write-shape and mechanism derivation
2. Use this companion for:
   • infra-first problem recognition
   • infra archetype selection
   • infra technology silhouettes
   • infra presentation script
   • infra-specific prompt mappings

If a prompt is clearly user/product/workflow oriented, use the main interview framework page directly.

Infra First Branch #

Treat the prompt as infrastructure-first if the dominant question is about one or more of:

• coordination
• routing
• replication
• control-plane propagation
• ordering
• partition ownership
• serving substrate
• cache or log semantics

Typical signals:

• queue, pub/sub, stream, broker
• cache, key-value, session, lock service
• load balancer, gateway, CDN
• service discovery, config, coordination, leader election
• scheduler, serverless worker substrate
• metadata store, distributed ID generation

Infrastructure Archetypes #

Use these as the first decomposition shortcut before filling the shared worksheets.

Canonical set:

• I01 Coordination / Consensus Metadata
• I02 Claim / Lease / Exclusive Ownership
• I03 Due-Time Release + Claimable Run
• I04 Frontier Scan + Claimable Run
• I05 Append Log + Consumer Progress
• I06 Projection / Index / Search Pipeline
• I07 Cache / Origin Projection / Edge Delivery
• I08 Traffic Shaping / Admission Control
• I09 Sequence / Identifier Generation
• I10 Membership / Presence / Registry
• I11 Control Plane + Snapshot Distribution
• I12 Workflow + External Side Effect
• I13 Shared Subject Coordination
• I14 Immutable Artifact Namespace + Delivery
• I15 Execution Fleet + Worker Substrate
• I16 Key-Scoped Mutable State / Replicated KV
• I17 Traffic Steering / Request Mediation Plane
• I18 Telemetry / Time-Series Pipeline
• I19 Replicated Chunk / Block / File Storage Substrate

Use the dominant archetype first, then compose supporting ones as:

• input
• output
• decorator / middleware
• substrate

For the full taxonomy with entities, source of truth, write paths, read paths, sequence shapes, failure prevention and repair, scaling bottlenecks, and archetype connections, use:

• infra-archetype-taxonomy-reference.md

If an infra prompt still feels overlapping after archetype selection, add the runtime overlay from:

• secondary-execution-component-overlay.md

That is most useful for:

• scheduler and workflow systems
• fleets and serverless substrates
• streaming and projection pipelines
• telemetry systems
• storage repair and rebalance systems

Common Infrastructure System Mappings #

Default Technology Silhouettes #

This section is shape-first, not vendor-first. Recall the storage, coordination, and serving shapes before naming concrete products.

Rule:

1. pick the dominant archetype
2. recall the silhouette
3. then choose products that fit the shape and NFRs

Infrastructure Rendering #

Use this verbal sequence in infra rounds.

1. “I’ll first normalize the requirements into state mutations, serving paths, and control or maintenance flows.”
2. “I’ll identify the correctness-critical state and the scopes where ordering, exclusivity, or coordination matter.”
3. “I’ll identify the smallest primary state needed to preserve authoritative system state.”
4. “For each critical path, I’ll state the hard invariants.”
5. “Then I’ll declare the execution context that constrains valid mechanisms.”
6. “Then I’ll classify the mutation and coordination shapes and choose mechanisms from the derived predicates.”
7. “Then I’ll define how serving paths read authoritative, replicated, or derived state.”
8. “Then I’ll cover retries, crashes, replication, and scaling bottlenecks.”

Infrastructure Normalization Hints #

Map infra prompts into the shared operation language using these common aliases:

This keeps infra prompts inside the same canonical field graph instead of inventing a second framework.

Infra Prompt Checklist #

Before leaving baseline design, make sure you have answered:

• what is the authoritative state?
• what is the correctness scope: key, partition, shard, replica group, or global?
• where does ordering matter?
• where does exclusivity or leadership matter?
• what can become stale, and what cannot?
• what happens when a holder crashes?
• what is the first hotspot at scale?

If these are explicit, the rest of the shared worksheet usually becomes straightforward.