388 templates · page 4 of 4
Architecture diagram templates
C4 model, system context, deployment, network topology.
Teaching Case — The Addresses Under a Correct-Looking Picture
Every box is in the right place. Two availability zones, a public load balancer, private application subnets, isolated data subnets — a diagram that would pass any review held over a screen. The arithmetic under it says something else: a subnet declared outside its own VPC, a /22 that silently swallows the /24 next to it, a management network numbered from documentation space no packet reaches, an address written where a block was meant, and a /29 asked to hold eight machines. Not one of those is visible in the drawing, and every one of them is decidable from the text. That is the entire case for checking the numbers rather than printing them.
Cloud architectureSysML v2 — Fuel System, Wired Correctly
The reference model, and the one to copy. A tank, a pump and an engine joined by a typed fuel interface, with the filler neck as a boundary port of the vehicle. Every port opposes the port it meets, every interface binds its ends in the order its definition declares, the payload conforms, and the item arriving at the boundary continues to something inside. Reports clean — and the figure is byte-for-byte the same as the next template's, which does not.
SysML v2 (structure)Teaching Case — One Character, Every Direction Reversed
The same fuel system with a single `~` deleted from the pump's inlet. The connection list is byte-identical, the figure is pixel-identical, and every direction in the joint has reversed: `feed` is now `out` at both ends and `spill` is `in` at both, so there are two suppliers, two consumers and nothing transferable. This is the commonest error in hand-written SysML v2 and it is invisible at any zoom. Open it beside the template above.
SysML v2 (structure)Teaching Case — An Interface Bound the Wrong Way Round
A drawn line has no ends. `connect pump.inlet to tank.outlet` and `connect tank.outlet to pump.inlet` are the same segment between the same two squares, and the definition that says which port belongs at which end is on another page. The engine evaluates the conformance predicate twice — in declared order and reversed — so it can say specifically that the ends are swapped and that exchanging them fixes it, rather than only that something does not conform.
SysML v2 (structure)Teaching Case — A Redefinition That Redefined Nothing
A redefinition is the one construct where a typo does not fail. `part redefines engien : TurboEngine;` does not replace the inherited `engine` — it silently declares a SECOND feature beside it, so the specialized vehicle has two engines. The compartment lists a part called `engien` in exactly the font it would list a correct one, and the inherited engine is not drawn at all because inherited features usually are not. The second finding here is the sibling defect: a redefinition that widens the multiplicity it replaces, so the specialization stops requiring what its supertype required.
SysML v2 (structure)Teaching Case — A System That Cannot Be Built
`Assembly` composes a `Subassembly`, which composes a `Module`, which composes an `Assembly`. Composition is ownership, so no instance of any of the three can ever be constructed — building one requires building itself. It draws as three rectangles and three composition lines, usually across two pages of a decomposition view, and nobody traces the loop by eye. The same document also holds a `ref part` cycle, which is perfectly legal: a reference is not ownership, and this engine excludes reference edges deliberately rather than reporting the two together.
SysML v2 (structure)Teaching Case — What a Library This Engine Does Not Carry Looks Like
The most important template in this set, and nothing in it is wrong. Every real SysML v2 model opens with `import ISQ::*`, and the quantity kinds it brings live in a model library shipped with the standard that this engine does not carry. So `ISQ::MassValue` is reported as a GAP with the reason — not as an error against a type that is perfectly correct, and not as a pass on a name that was never checked. Delete the import line and the same names become hard findings, because then nothing could have supplied them. Same model, two honest answers, and collapsing them in either direction is how a checking tool gets switched off in an afternoon.
SysML v2 (structure)Teaching Case — An Arrow Carrying the Wrong Thing
A flow declares what it carries and the feature it arrives at declares what it accepts, and the arrow is identical whether or not those agree. Here coolant is routed into a port that accepts fuel. Conformance is decided by the `:>` declarations in the document and by nothing else — not by the names looking alike, not by the two types having similar features — so `Petrol` reaching a `Fuel` port passes because the document says `Petrol :> Fuel`, and `Coolant` reaching the same port does not.
SysML v2 (structure)SysML v2 — Avionics Bay, Power and Data
A larger model that reports clean: two independent port definitions — one for 28 V power, one for a data bus — a bus controller, two line-replaceable units and a power distribution unit, with the bay's boundary ports carrying both. It shows the pattern real models are built on: one interface definition per contract, conjugation on the consuming side, and the whole interior wired so that nothing arriving at the boundary stops there.
SysML v2 (structure)Rack A1 — the Reference Elevation
The one to copy. A 42U cabinet with a stated power budget and floor loading, every device in a unit of its own, nothing reaching past either end, and headroom stated in both watts and kilograms. The panel reports the free capacity and the tallest device that would still fit, which is the number somebody planning the next install actually wants. Reports clean.
Server RackTeaching Case — Two Devices in One Unit
Two devices declared at U 20, in a rack where everything else is spaced correctly. Drawn by any tool that draws what it is handed, the second is painted over the first at full width and the first disappears — so the figure shows seven devices where the document declares eight, in a plausible slot with a plausible label, and nothing anywhere says a device is missing. Here they are drawn side by side in the unit they contend for, ringed, and the panel names both.
Server RackTeaching Case — A Device That Reaches Past the Rack
A 4U storage shelf placed at U 3, which reaches down to U 0 — a unit that does not exist — and a switch placed at U 30 in a 24U cabinet. The renderer this replaces clamped the top unit with `Math.min(units, at)`, so in a 12U rack a device at U 12, at U 20 and at U 99 produced byte-identical SVG: the author's mistake silently corrected into a drawing of a rack they never described. Neither device is drawn mounted here; both appear in a marked strip beside the frame, at the unit they claim.
Server RackTeaching Case — A Rack That Fits and Cannot Be Powered
Eight compute nodes in a 42U cabinet, every one in a unit of its own, nothing overhanging — an elevation that is correct in every way a drawing can be. It draws 5,280 W against a 4,000 W budget, and there is no arrangement of boxes that shows it: twenty servers fit in a rack whether they draw 4 kW or 14 kW, and the elevation is identical either way. Stated per device and per rack, it is exact arithmetic with no heuristics in it.
Server RackTeaching Case — A Budget With Nothing to Check It Against
The rack states a power budget and not one device states its draw, so there is nothing to add up. Reported as a GAP naming what is missing rather than as a budget that was met — a green tick over an unknown is worse than no tick at all, and a reader who sees findings and no gaps takes the reading as total. The occupancy half of the analysis still runs and still finds every device in a unit of its own, because two questions that can be answered separately should be.
Server RackLadder - Roller Door Open/Close Interlock
Eight rungs of a loading-bay roller door caught mid-travel with the close command sealed in: the open rung is held off by its own reverse interlock rather than by the buttons, the safety beam is clear so no reverse is latched, and the 180 s courtesy-light TOF is enabled by the moving door so its done bit keeps the bay lamp lit.
Ladder logic (PLC)Ladder - Lift Hall Call and Door Dwell
Nine rungs of a three-storey lift with a registered level-3 hall call and the car standing at level 1: the call latches on rung 2, the clear rung stays unpowered because the car has not arrived, the up command and hoist motor follow, and the 8 s door dwell has never been enabled so the door-open command is dead.
Ladder logic (PLC)Event Storm — Order Fulfilment
Retail order fulfilment across ordering, warehouse and delivery contexts, with two cross-context policies and an uncommanded delivery event the storm leaves on the wall.
Event stormingEvent Storm — Ride-Hailing Trip
Rider request, dispatch matching, trip and fare across four bounded contexts, with a driver cancellation event the model never causes.
Event stormingRisk Matrix — Information Security Risk Register (ISO 27005)
An ISO/IEC 27005 register for a fictional payroll SaaS covering nine threat scenarios, from ransomware in the build pipeline to supplier-payment fraud: controls cut exposure from 114 to 53 (−54%) and take all four Critical risks out of the top band, while the edge VPN, the build pipeline and the open-source supply chain stay High and above appetite, each with a treatment. Illustrative register.
Risk matrixDecision Matrix — Event Streaming Platform (ADR)
An architecture decision record for an event streaming platform: measured throughput, ops effort and run cost alongside scored replay, ordering, tooling and lock-in, in three weighted groups. The classic broker fails the 60k msg/s must-have; self-hosted Kafka ranks first at 3.88 of 5, 0.20 ahead of the managed service — a fragile lead that reverses if ops effort's weight rises from 18% to 22.4%. Illustrative values.
Decision matrix (weighted / Pugh)Roadmap — Core Banking Modernisation, 2026–2029
A four-year technology roadmap for a fictional building society replacing its mainframe core, drawn by half-year: 17 items (5 done, 5 in progress, 7 planned) and 2 milestones across five lanes with a 15 Mar 2027 status date. All 17 dependencies finish before their dependents start; the longest chain, six steps, runs from core vendor selection through the cloud core build and the savings, mortgage and current-account migrations to the mainframe switch-off at the end of 2029. Illustrative roadmap.
RoadmapMicroservices Architecture (D2)
Gateway, services, datastores, and an event bus in D2.
D2Deployment Diagram (PlantUML)
Nodes and artifacts in a simple production deployment.
PlantUMLEvent-driven Architecture (D2) — Broker and Event Store
Producers, a broker, and consumers in an event-driven system.
D2Module Dependency Graph (Graphviz) — Frontend Layers
Visualize how application modules depend on each other.
Graphviz (DOT)C4 System Context (Structurizr)
A C4 model — context and container views for an online store.
Structurizr DSLThree-tier Web App (D2)
The classic presentation / logic / data tiers.
D2Microservices (PlantUML Component)
Gateway, services, databases and an event bus.
PlantUMLKubernetes Service (D2)
Ingress to a service load-balancing across pods.
D2Event-Driven Architecture (D2) — Dead-Letter Queue
Producer, topic, consumers and a dead-letter queue.
D2Layered Architecture (Nomnoml)
Presentation, application, domain and infrastructure layers.
NomnomlWeb Deployment (PlantUML)
Browser, CDN, web server, cache and database nodes.
PlantUMLMicroservices Mesh (D2)
A gateway fronting services that call each other and data stores.
D2Network Tiers (D2)
Internet through WAF and load balancer to web, API and DB.
D2Module Dependency Graph (Graphviz) — App Services
Direction of dependencies between modules.
Graphviz (DOT)Network Topology (Graphviz)
A simple LAN behind a router.
Graphviz (DOT)SaaS System Context (Structurizr / C4)
A C4 context diagram for a SaaS platform.
Structurizr DSLSystem Context (Mermaid C4)
A C4 context diagram for a payments platform.
MermaidServerless Architecture (D2)
API gateway, functions, a queue and a table.
D2Small Office (Floor Plan)
A small office with rooms, a door and windows.
Floor plan (2D)Saga Pattern (Mermaid Sequence)
Distributed transaction with compensating actions.
MermaidCQRS + Event Sourcing (D2)
Separate command and query paths with a projector.
D2Service Call Graph (Graphviz)
Inter-service calls behind a gateway.
Graphviz (DOT)Strangler Migration (D2)
A strangler facade peeling services off a monolith.
D2Payment Flow (D2)
Checkout through gateway and bank to a ledger.
D2IoT Telemetry (D2)
Sensors through a broker to storage and alerts.
D2Web App Containers (Structurizr / C4)
A C4 container diagram for a web application.
Structurizr DSLRequest Path (Pikchr)
Client through a load balancer to a database.
PikchrMulti-Region Deployment (D2)
DNS routing to regional stacks with replication.
D2Server Rack (Rack Diagram)
A 24U rack elevation for a small stack.
Server RackNetwork Rack (Rack Diagram)
A 12U comms rack.
Server RackStorage Rack (Rack Diagram)
A 42U storage rack with disk shelves.
Server RackRBD — Earth Observation Payload Chain
Five-year mission reliability for an optical imaging smallsat, chaining a cold-standby computer pair, redundant reaction wheels flown four-of-five and a duplex X-band downlink behind a single-string telescope.
Reliability block diagramDSM — Payments Monolith Decomposition
Fifteen modules of a payments monolith listed in package order, where partitioning cuts 15 backwards dependencies to 4 and leaves an eight-module ledger and settlement core no extraction order untangles.
Design structure matrixQueueing Network — Fleet Telemetry Ingest
A 4,000-message-a-second vehicle telemetry pipeline across gateway, decoder, enrichment, a bounded rule engine pool and column storage, with a replay loop from the dead-letter path back into decoding.
Queueing networkEvent Storm — Rail Ticketing and Delay Repay
Retailing, fulfilment and delay repay contexts for a train operator, with a compensation policy triggered by a journey completed late, a journey search written up as a command and a refund event nobody produces.
Event stormingExcalidraw — Checkout Architecture Whiteboard Sketch
The architecture a team draws on a whiteboard before writing the design doc: mobile app through an API gateway to the orders and payments services, the orders database, the external card processor behind 3-D Secure, and an order.placed event feeding the email worker — with the open question about idempotency keys pencilled beside it.
ExcalidrawWireViz — CANopen Drop Cable, DB-9 to M12 A-Coded (CiA 303-1)
A CANopen drop cable wired to the CiA 303-1 pinouts: DB-9 female (CAN_L pin 2, CAN_GND 3, shield 5, CAN_H 7, CAN_V+ 9) to a 5-pin M12 A-coded plug (shield 1, CAN_V+ 2, CAN_GND 3, CAN_H 4, CAN_L 5), over a shielded four-core cable with CAN_H and CAN_L as the white–blue pair; the screen is terminated to both connector shells, so the optional CAN_SHLD pins carry no conductor.
WireVizWireViz — Modbus RTU (RS-485) Cable, RJ45 to Terminal Block
A two-wire Modbus RTU cable to the pinout in the Modbus over Serial Line specification: RJ45 pin 4 is D1 (B/B′), pin 5 is D0 (A/A′) and pin 8 is Common, landed on a three-way terminal block at the instrument end. D0 and D1 share one twisted pair, Common takes the second, and the overall screen is left free here so it can be bonded to protective earth at a single point in the installation.
WireVizWireViz — Ethernet Crossover Cable, T568A to T568B
An eight-wire 100BASE-TX crossover cable: one RJ45 terminated T568B, the other T568A, so the transmit pair on pins 1 and 2 arrives on the receive pins 3 and 6 at the far end, and pins 4, 5, 7 and 8 run straight through. Conductor colours are the T568B colours of the near end.
WireVizWireViz — USB 2.0 Cable, Type-A Plug to Micro-B Plug
A USB 2.0 cable to the USB-IF colour convention: VBUS red, D− white, D+ green and GND black from the four-pin Type-A plug to the five-pin Micro-B plug, with the Micro-B ID pin left unconnected (which is what makes the far end a device rather than an On-The-Go host) and the braid terminated to both plug shells.
WireVizWireViz — ARM Debug Adapter, 10-Pin Cortex to 20-Pin JTAG
An adapter from the 0.05-inch 10-pin Cortex Debug connector to the 0.1-inch 20-pin ARM JTAG connector: VTref, SWDIO/TMS, SWCLK/TCK, SWO/TDO, TDI and nRESET each land on their 20-pin counterparts (1, 7, 9, 13, 5 and 15), with the two Cortex ground pins carried on separate conductors to grounds 4 and 6.
WireVizSymbolator — AXI4-Lite Register Slave (VHDL)
The block symbol of an AXI4-Lite slave register file with all five AXI channels grouped as an FPGA datasheet draws them — write address, write data, write response, read address and read data — plus clock, active-low reset and an interrupt output. Widths follow the generics, with the write strobe one bit per data byte.
Symbolator (HDL)Symbolator — UART Transceiver With Byte Interface (VHDL)
A UART core's symbol: generics for the system clock and baud rate, a valid/ready byte stream on the transmit side, a valid byte plus framing and overrun error flags on the receive side, and the two serial pins. The serial pins sit in their own group so the board-level connection is obvious.
Symbolator (HDL)Symbolator — SPI Master With Configurable Mode (VHDL)
A parameterised SPI master: word width, clock divider and slave-select count as generics, CPOL and CPHA as run-time inputs so one block serves all four SPI modes, a start/busy/done handshake for the transfer word, and the SCLK, MOSI, MISO and one-hot active-low chip-select pins.
Symbolator (HDL)Symbolator — True Dual-Port Block RAM (VHDL)
A true dual-port RAM as inferred into FPGA block RAM: two fully independent ports, each with its own clock, enable, byte-write enables, address and data in and out, so the symbol reads as two mirror-image interfaces. Depth is 2^ADDR_WIDTH words and the write-enable width is one bit per byte of data.
Symbolator (HDL)Symbolator — FIR Filter With AXI4-Stream Interfaces (VHDL)
A streaming FIR filter's symbol: tap count and sample and coefficient widths as generics, an AXI4-Stream slave input and master output (tdata, tvalid, tready, tlast), and a coefficient-load port. The output is wider than the input by the coefficient width plus growth bits, as a full-precision FIR accumulator requires.
Symbolator (HDL)Flame Graph — Go gRPC Pricing Service (pprof CPU)
A 30-second pprof CPU profile of a Go pricing service at 1,800 requests per second (6,680 samples): regular expressions take 45.7% of the CPU, 18.2% of it recompiling the same rule patterns on every call, and garbage collection plus allocation take another 26.6% — the pattern that says "compile once at load, cache the *regexp.Regexp". Illustrative values.
Flame GraphFlame Graph — Node.js Server-Side Rendering of a Category Page
A --cpu-prof capture of a Node.js server rendering a 120-product category page (3,220 samples): 19.9% goes to constructing a new Intl.NumberFormat for every price, the 25.9% spent parsing and re-serialising the catalogue payload says the page ships far more data than it shows, and garbage collection takes 14%. Illustrative values.
Flame GraphEngineering — service architecture
Engineering vertical — system / service / datastore / actor. Typed FlowScript for software architecture. Keywords: C4, container, system context, architecture.
FlowScriptEngineering — Change Request Flow
A change-request pipeline through a service estate: requests raised against the services below, reviewed, approved, deployed. Typed FlowScript for software architecture. Keywords: C4, container, system context, architecture.
FlowScriptEngineering — C4 container view of an ML scoring platform
C4 container view of a real-time ML scoring platform: the systems that call it, the serving and training services, the shared feature and model services, and the stores each owns — where an architecture review starts. Typed FlowScript for software architecture. Keywords: C4, container, system context, architecture.
FlowScriptEvidence-grounded retrieval architecture
Trace permissions and document versions through retrieval and answer verification. Typed FlowScript for software architecture. Keywords: C4, container, system context, architecture.
FlowScriptEvent-driven order architecture
Separate reservation, payment and fulfilment boundaries; annotate compensating actions. Typed FlowScript for software architecture. Keywords: C4, container, system context, architecture.
FlowScriptSensor-to-asset assurance architecture
Keep rejected readings traceable while accepted telemetry flows to operational views. Typed FlowScript for software architecture. Keywords: C4, container, system context, architecture.
FlowScriptPrivacy-aware analytics architecture
Model approval, minimisation and disclosure checks as distinct components. Typed FlowScript for software architecture. Keywords: C4, container, system context, architecture.
FlowScriptOffline fieldwork synchronisation
Distinguish local drafts from canonical records and resolve conflicts before publication. Typed FlowScript for software architecture. Keywords: C4, container, system context, architecture.
FlowScriptAvailability budget — regional API against a 99.99 % monthly SLO
Reliability block diagram of a three-AZ regional payments API stated in MTBF and MTTR, computing composite availability against a 99.99 % monthly SLO and ranking which block owns the failure — the arithmetic an SRE or architect must show before committing to an availability target.
Reliability block diagramApplication landscape interface matrix — before an ERP cutover
Dependency structure matrix of a retail group's 14 core applications and their 41 interfaces, partitioned to show that all but one sit in a single irreducible cycle — the integration-landscape analysis an enterprise or integration architect produces to plan an ERP cutover sequence.
Design structure matrixSAN dual-fabric zoning — single initiator, single target
Fibre Channel storage area network design: two air-gapped fabrics with switch domain IDs and ISLs, host HBA and array front-end port WWPNs, and the zoneset with its single-initiator single-target zone names — the zoning drawing a storage engineer must hand to change control before an array or host is cabled.
Graphviz (DOT)Transactional outbox and consumer deduplication
Shows atomic outbox creation, at-least-once delivery and idempotent consumption. Original worked design example; adapt responsibilities, thresholds and assumptions to your system.
MermaidAuthorization code exchange with PKCE
Separates browser state validation, PKCE binding and resource-server authorization. Original worked design example; adapt responsibilities, thresholds and assumptions to your system.
MermaidWebhook verification and replay protection
Includes raw-body signature validation, replay controls and durable acceptance before acknowledgement. Original worked design example; adapt responsibilities, thresholds and assumptions to your system.
MermaidLease-based job processing and fencing
Shows why lease expiry alone is insufficient and stale workers need fencing at the resource. Original worked design example; adapt responsibilities, thresholds and assumptions to your system.
MermaidCredential rotation with overlap window
Separates preparation, compatibility overlap, migration verification and irreversible old-key revocation. Original worked design example; adapt responsibilities, thresholds and assumptions to your system.
MermaidRegional failover with shared control plane
Separates health evidence, traffic routing and data-store promotion; replication and failover assumptions remain explicit. Original worked design example; adapt responsibilities, thresholds and assumptions to your system.
Graphviz (DOT)Identity-aware application access boundaries
Makes authentication, authorization and service-to-service access separate trust decisions. Original worked design example; adapt responsibilities, thresholds and assumptions to your system.
Graphviz (DOT)Strangler migration with reconciliation
Includes data reconciliation and gradual routing with explicit migration ownership boundaries. Original worked design example; adapt responsibilities, thresholds and assumptions to your system.
Graphviz (DOT)