# The Computing Series -- Engineering Vocabulary Reference A shared vocabulary for engineering teams and AI tools. Use these codes in code reviews, architecture decision records, design documents, and AI prompts to make decisions precise and disagreements legible. Source: computingseries.com -- The Computing Series (8 Books, 9 Frameworks, 12 Threads) Author: Harish Kumar Licence: Creative Commons Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/ You are free to use, share, copy, adapt, and redistribute this file for any purpose, including commercial use, provided you give appropriate credit: "The Computing Series -- computingseries.com" --- ## How to use **In a code review:** > FM8 here -- the frontend assumes the API always returns `user.role` but that is not > guaranteed in the contract. If the backend team renames this field the frontend breaks silently. **In an architecture decision record (ADR):** > Decision: pre-compute feed at write time. > Tradeoff: AT4 -- choosing precomputation because read latency matters more than write cost. > Exposes: FM7 -- cache stampede on cold start. > Mitigation: lazy warm-up with staggered TTLs per user cohort. **In an oncall handoff:** > FM11 on the payments retry queue -- no metric for depth, no alert if it stops draining. **With AI tools (Claude, ChatGPT, Copilot):** Paste this file into your system prompt or context window. The AI can then use the same codes you use, flag failure modes by number, and name tradeoffs precisely rather than generically. Example prompt addition: "Use AT/FM/T/P/L codes from The Computing Series vocabulary when discussing design decisions or flagging risks." **Pattern recognition shortcut:** When you spot a pattern (T5 Caching), its associated tradeoffs and failure modes activate automatically (AT4 + FM7). The pattern is a compressed pointer to the questions you must answer. --- ## AT -- Architecture Tradeoffs (10) Every design decision resolves one of these. Name it before writing code. | Code | Name | You are choosing between | |------|-------------------------------|---------------------------------------------------| | AT1 | Consistency vs Availability | Correct data vs system stays up | | AT2 | Latency vs Throughput | Speed per request vs requests per second | | AT3 | Simplicity vs Flexibility | Easy to understand vs easy to extend | | AT4 | Precomputation vs On-Demand | Pay at write time vs pay at read time | | AT5 | Centralisation vs Distribution| Single authority vs no single point of failure | | AT6 | Generality vs Specialisation | All cases vs common case optimised | | AT7 | Automation vs Control | System decides vs human decides | | AT8 | Coupling vs Cohesion | Independent deployment vs co-located logic | | AT9 | Correctness vs Performance | Right answer vs fast answer | | AT10 | Synchronous vs Asynchronous | Immediate response vs deferred processing | --- ## FM -- Failure Modes (12) Every component introduces at least one. Name it before shipping. | Code | Name | What goes wrong | |------|-------------------------------|---------------------------------------------------| | FM1 | Single Point of Failure | One component dies, system dies | | FM2 | Cascading Failures | One failure triggers the next | | FM3 | Unbounded Resource Consumption| Memory / connections / threads grow without limit | | FM4 | Data Consistency Failure | Components disagree on state | | FM5 | Latency Amplification | Small latencies multiply across hops | | FM6 | Hotspotting | One node gets disproportionate load | | FM7 | Thundering Herd | Mass simultaneous retry overwhelms recovery | | FM8 | Schema / Contract Violation | One side of a boundary changes, other breaks | | FM9 | Silent Data Corruption | Wrong data propagates without alerts | | FM10 | Security Breach | Unauthorised access to data or compute | | FM11 | Observability Blindness | System fails but team cannot see where | | FM12 | Split-Brain | Two nodes both think they are primary | --- ## T -- Threads / Structural Patterns (12) Recognising the pattern activates its associated AT and FM constraints. | Code | Name | When you see it | Key AT/FM | |------|-------------------|------------------------------------------------------|--------------| | T1 | Hashing | Key distribution, dedup, sharding | AT5, FM6 | | T2 | Trees | Hierarchical data, indexes, sorted access | AT2, FM3 | | T3 | Graphs | Dependencies, relationships, routing | AT3, FM2 | | T4 | Queues | Async processing, buffering, backpressure | AT10, FM3 | | T5 | Caching | Memoization, CDN, read-through, precomputed results | AT4, FM7 | | T6 | Redundancy | Replication, backups, failover, multi-region | AT1, FM1 | | T7 | State Machines | Lifecycle, workflows, protocol state | AT9, FM4 | | T8 | Divide & Conquer | Sharding, MapReduce, microservices | AT5, FM2 | | T9 | Consensus | Leader election, distributed locks, quorum | AT1, FM12 | | T10 | Encoding | Serialisation, schema evolution, API versioning | AT3, FM8 | | T11 | Feedback Loops | Rate limiting, circuit breakers, autoscaling | AT7, FM2 | | T12 | Tradeoffs | Every decision is an optimisation under constraints | AT*, FM* | --- ## MM -- Mental Models (12) Lenses for interpreting a system before designing it. | Code | Name | What it models | |------|----------------------|-------------------------------------------------------| | MM1 | Transformation | Input -> process -> output | | MM2 | Search | Find items satisfying a predicate | | MM3 | Optimisation | Minimise/maximise under constraints | | MM4 | Flow | Resources moving through a network | | MM5 | State | A system whose outputs depend on history | | MM6 | Networks | Nodes + edges + emergent behaviour | | MM7 | Feedback | Output fed back as input | | MM8 | Concurrency | Multiple agents operating simultaneously | | MM9 | Redundancy | Extra capacity for fault tolerance | | MM10 | Layered Abstraction | Complex detail hidden behind a simpler interface | | MM11 | Indirection | Decouple caller from callee via a level of reference | | MM12 | Tradeoffs | Every design choice has a cost | --- ## P -- Engineering Principles (15) Absent principles predict specific failure modes. | Code | Name | Rule | Absent -> | |------|----------------------|---------------------------------------|-----------------------------------------| | P1 | Abstraction | Hide irrelevant detail | FM8 (callers depend on internals) | | P2 | Modularity | Independently replaceable units | FM2 (blast radius unlimited) | | P3 | Composability | Small units combine | FM3 (monoliths grow unbounded) | | P4 | Separation of Concerns | Each component owns one thing | FM4 (shared mutable state) | | P5 | Idempotency | Same input -> same output, always | FM4 (duplicate retries corrupt data) | | P6 | Reproducibility | Any environment gives same result | FM8 (works locally, breaks in prod) | | P7 | Immutability | Never change data in place | FM9 (silent overwrites) | | P8 | Locality | Keep data close to computation | FM5 (latency amplification) | | P9 | Fault Tolerance | Failures degrade gracefully | FM1 (single failure kills the system) | | P10 | Observability | The system explains itself | FM11 (cannot diagnose failures) | | P11 | Consistency | Single source of truth | FM4 (split-brain data) | | P12 | Security Boundaries | Trust is explicitly granted | FM10 (over-privileged access) | | P13 | Fail Fast | Surface errors early | FM9 (bad state propagates silently) | | P14 | Least Privilege | Grant only what the task requires | FM10 (breached credential has access) | | P15 | Measure & Adapt | Optimise based on data | FM11 (optimising the wrong thing) | --- ## L -- Engineering Laws (16) Constraints that cannot be negotiated away. | Code | Name | The law | |------|-----------------------|-------------------------------------------------------------------------| | L1 | Amdahl's | Parallelism speedup bounded by the sequential fraction | | L2 | Moore's | Transistor density doubles roughly every 2 years | | L3 | CAP | Choose 2 of: Consistency, Availability, Partition-tolerance | | L4 | Little's | L = lambda * W (queue depth = arrival rate x wait time) | | L5 | Metcalfe's | Network value proportional to n^2 | | L6 | Brooks's | Adding engineers to a late project makes it later | | L7 | Hofstadter's | Always takes longer than expected, even accounting for this law | | L8 | Parkinson's | Work expands to fill the time available | | L9 | Goodhart's | When a measure becomes a target, it ceases to be a good measure | | L10 | Conway's | Architecture mirrors the communication structure of the team | | L11 | Gall's | Complex systems that work evolved from simple systems that worked | | L12 | Postel's | Be conservative in what you send, liberal in what you accept | | L13 | Leaky Abstractions | All non-trivial abstractions leak | | L14 | Hyrum's | Any observable behaviour of an API will be depended upon | | L15 | Pareto | 80% of effects come from 20% of causes | | L16 | Linus's | With enough eyes, all bugs are shallow | --- ## A -- System Archetypes (6) Most systems are one of these, or a combination. The archetype reveals likely tradeoffs and required infrastructure before the first line of code is written. | Code | Name | Canonical shape | Core AT | Core FM | |------|----------------------------|----------------------------------------------------|-------------|--------------| | A1 | Search & Discovery | Index -> query -> rank -> return | AT2, AT4 | FM6, FM3 | | A2 | Social & Communication | Users -> relationships -> feed -> notifications | AT1, AT10 | FM4, FM6 | | A3 | Marketplace & Transaction | Buyers -> sellers -> matching -> payment | AT1, AT9 | FM4, FM10 | | A4 | Media Delivery | Ingest -> encode -> store -> stream | AT2, AT4 | FM3, FM5 | | A5 | Data Intelligence | Collect -> store -> transform -> analyse -> serve | AT4, AT9 | FM9, FM11 | | A6 | Platform & API | Core resources exposed as an extensible API | AT3, AT8 | FM8 | --- ## IC -- Infrastructure Components (26) Each has a canonical role. Using one component for another role is a design smell. | Code | Name | Role | |------|-------------------------------|-------------------------------------------------------------| | IC1 | DNS | Domain -> IP resolution; globally cached | | IC2 | CDN | Edge-cached static assets; geo-distributed | | IC3 | Load Balancer | Distribute traffic across instances | | IC4 | API Gateway | Auth, rate-limit, routing at network edge | | IC5 | Service Mesh | Sidecar: inter-service auth / observability / retries | | IC6 | Rate Limiter | Token-bucket / sliding-window throttle | | IC7 | Application Server | Stateless compute; business logic | | IC8 | Background Worker | Async job runner (Celery, Sidekiq, BullMQ) | | IC9 | Cache Server | In-memory KV store (Redis, Memcached) | | IC10 | Synchronous RPC / REST | Request/response inter-service call | | IC11 | Service Discovery | Registry of live instances (Consul, Kubernetes DNS) | | IC12 | Relational DB (ACID) | Transactions, foreign keys, strong consistency | | IC13 | Message Queue / Event Stream | Durable async messaging (Kafka, SQS, RabbitMQ) | | IC14 | NoSQL Document Store | Schema-flexible JSON documents (MongoDB, DynamoDB) | | IC15 | Key-Value Store | Simple get/set at scale (DynamoDB, etcd) | | IC16 | Wide Column Store | Sparse table, high write throughput (Cassandra, BigTable) | | IC17 | Object Storage | Blob store, infinite scale (S3, GCS) | | IC18 | Search Index | Full-text + faceted search (Elasticsearch, Typesense) | | IC19 | Vector Database | Embedding similarity search (Pinecone, pgvector) | | IC20 | Batch Processor | Large-scale offline jobs (Spark, Hadoop, BigQuery) | | IC21 | Stream Processor | Continuous real-time computation (Flink, Kafka Streams) | | IC22 | Metrics System | Time-series telemetry (Prometheus, Datadog) | | IC23 | Log Aggregator | Centralised log collection and search (ELK, Loki) | | IC24 | Distributed Tracing | Request-flow across services (Jaeger, Zipkin, OTEL) | | IC25 | Config Management | Centralised feature flags and env config (Vault, LaunchDarkly) | | IC26 | Orchestrator / Scheduler | Workload placement and lifecycle (Kubernetes, Nomad) | --- ## Decision block format Use this in ADRs, PR descriptions, design documents, and AI prompts: ``` Decision: [what you chose] Tradeoff: AT[N] -- choosing [pole] because [reason] Exposes: FM[N] -- [what could go wrong] Mitigation: [how the failure mode is addressed] ``` --- ## Seven questions before any architecture is complete 1. How does it scale? What breaks at 10x current load? (FM3, FM6) 2. How does it fail? What happens when each component is unavailable? (FM1, FM2) 3. Where is the state? Can it replicate? What happens on divergence? (FM4, FM12) 4. What is the latency budget? How many network hops? What is the P99? (FM5) 5. How does it evolve? Can schemas and APIs change without breaking consumers? (FM8) 6. How is it secured? What has access to what? (FM10) 7. Can you observe it? If it fails at 3 AM, can oncall diagnose it? (FM11) --- The full treatment -- compression blocks, three-level exercises, and applied examples across 202 chapters -- is in The Computing Series. computingseries.com