388 templates · page 3 of 4
Architecture diagram templates
C4 model, system context, deployment, network topology.
Pub/sub topology
Producer → broker → multiple subscribers.
PikchrTiny network
Internet → firewall → switch → 3 servers.
PikchrHello Bytefield
Minimal starter — header / payload / gap. The canonical introduction to bytefield-svg's DSL.
BytefieldTCP segment header
Classic TCP header layout — 32-bit columns, source/dest ports, sequence and ack numbers, flags strip and window size.
BytefieldIPv4 header
RFC 791 — Version / IHL / DSCP, length, identification, flags + offset, TTL, protocol, checksum, addresses.
BytefieldELF identification block
First 16 bytes of every ELF binary — the magic number, class, endianness, version, OS / ABI bytes that the linker reads first.
BytefieldFilesystem superblock
Stylised on-disk superblock layout — magic, block size, inode counts, generation, journal pointer.
BytefieldInternet banking system (C4)
Adapted from the canonical Structurizr 'Big Bank plc' example — customers, internet banking system and the mainframe it talks to.
Structurizr DSLMulti-tenant SaaS containers
Container-level view of a SaaS product — web app, API, async worker, Postgres, object storage, plus a third-party billing system.
Structurizr DSLIoT ingest platform
Edge devices → MQTT broker → ingest → time-series database → dashboards. The classic IoT shape, in C4.
Structurizr DSLData pipeline (ASCII)
A linear ingest → transform → load pipeline drawn in pure ASCII — SVGBob promotes boxes, arrows and joins to crisp SVG.
SVGBob (ASCII)Network topology (ASCII)
Internet → firewall → switch → three application servers. The kind of diagram you'd otherwise hand-draw in a PR description.
SVGBob (ASCII)RS-232 null-modem cable
Classic null-modem cable between two DB-9 connectors — TX crosses to RX, RTS to CTS, plus ground.
WireVizI²C sensor breakout
MCU → I²C sensor module — VCC, GND, SDA, SCL, four-wire harness with colour-coded conductors.
WireVizIngest pipeline (Ditaa)
Source → queue → worker → DB. Ditaa's `cBLU` / `cGRE` markers tint each box.
Ditaa (ASCII)Client / server / cache
Classic three-box system view with a colour-coded cache layer.
Ditaa (ASCII)Up/down counter (VHDL)
Parameterised counter entity — symbol with grouped clock/control and data ports.
Symbolator (HDL)Synchronous FIFO
Classic FIFO block symbol — write/read interfaces with status flags.
Symbolator (HDL)Corporate network — 3 subnets
DMZ + internal + database subnets with web servers, DB cluster and a router.
Network (nwdiag)Home lab network
ISP gateway → router → wifi + wired LAN with a NAS and a few clients.
Network (nwdiag)AWS VPC — multi-AZ
Public subnet + private app subnet + private DB subnet across two AZs.
Network (nwdiag)UDP header
Classic 64-bit UDP header — source port, destination port, length, checksum. Bit-positions enforced.
Packet diagrams (packetdiag)TCP header — bit fields
Bit-precise TCP header. Compare with the bytefield-svg version for two takes on the same layout.
Packet diagrams (packetdiag)ICMP echo packet
Ping packet — Type / Code / Checksum / Identifier / Sequence number + payload.
Packet diagrams (packetdiag)FlowScript — service architecture
Engineering-vertical FlowScript example — C4 container view from `service`, `datastore`, `actor` types.
FlowScriptnwdiag — three-tier web app
DMZ → app → DB segmentation with explicit IPs.
Network (nwdiag)nwdiag — multi-AZ VPC
Two AZs with public and private subnets each.
Network (nwdiag)nwdiag — home lab
Router-segmented home lab with IoT VLAN.
Network (nwdiag)nwdiag — bank network zones
PCI-DSS-style segmentation: edge, app, card-data, backoffice.
Network (nwdiag)nwdiag — Kubernetes cluster
Control plane vs. worker subnets with ingress + egress.
Network (nwdiag)Structurizr — SaaS container view
Customer-facing SaaS with web, API, queue and DB.
Structurizr DSLStructurizr — internet banking
Classic C4 banking system with mobile and web channels.
Structurizr DSLStructurizr — IoT telemetry pipeline
Devices → MQTT → stream processor → warehouse.
Structurizr DSLStructurizr — two-sided marketplace
Buyer, seller, marketplace platform with payments.
Structurizr DSLPikchr — network topology (RFC style)
Classic plus-sign router topology.
PikchrPikchr — cache layers
Browser → CDN → cache → DB cascade.
PikchrD2 — event-driven architecture
Producers, queue, consumers with retry topic.
D2D2 — CDN edge architecture
Edge / regional / origin caching tiers.
D2D2 — saga (booking)
Hotel + flight + car saga with compensating actions.
D2D2 — IoT edge processing
Field devices, edge gateways, cloud ingest.
D2SVGBob — OSI stack
Seven-layer OSI model in ASCII.
SVGBob (ASCII)SVGBob — three tiers
Web → API → DB tier diagram.
SVGBob (ASCII)Ditaa — three-tier system
Web / API / DB drawn with ASCII boxes.
Ditaa (ASCII)Ditaa — event bus
Producer / bus / consumers ditaa diagram.
Ditaa (ASCII)Ditaa — cache aside
App → Cache → DB cache-aside pattern.
Ditaa (ASCII)Azure N-Tier Application
Azure n-tier web app: Front Door + gateway + App Service tier + managed data services.
WeaveGoogle Cloud Web Application
GCP web app: Cloud CDN + Cloud Load Balancing + Cloud Run / Compute Engine + managed data.
WeaveGoogle Cloud Network (VPC)
Global GCP VPC with regional subnets, Cloud Armor, Cloud NAT and VPC peering.
WeaveAWS VPC Network Diagram
AWS VPC: internet gateway, public subnet (ALB / bastion / NAT), private app + data subnets.
WeaveHybrid Cloud Architecture
On-premises data center connected over VPN / Direct Connect to cloud compute + data.
WeaveCloud Platform Stack (isometric)
Isometric platform architecture — ingestion funnel, compute cube, a processing gear, layered service mesh and a data-lake stack.
WeaveData Center Topology (isometric)
Isometric infrastructure — a load-balancer funnel, web/app tiers as 3-D cubes, a worker gear and stacked primary/replica storage.
WeaveMicroservices Mesh (3-D)
A service honeycomb behind an API-gateway cube, worker gears, a globe-spanning edge network and a database cluster.
WeaveObservability Stack (3-D)
A server fleet emits metrics through a pipeline into a time-series store that powers an SLO donut chart and a global status globe.
WeaveEvent-Driven Microservices
An edge network and API gateway publish to an event queue; a service mesh and worker pool consume events and persist to the database cluster.
WeaveCI/CD Pipeline — with Monitoring Loop
Commits trigger a build and test stage, promote through staging to production, with monitoring feeding back to the next commit.
WeaveData Lakehouse
Sources are ingested into a data lake, curated into a warehouse, and served to BI dashboards and ML models.
WeaveAWS — Three-Tier Web App in a VPC
Public / private / data subnets across two AZs: CloudFront and WAF at the edge, an ALB into an auto-scaled app tier, Aurora with a standby, and an async order path through SQS and Lambda.
WeaveEvent-Driven Serverless Pipeline
API Gateway to Lambda to EventBridge, fanned out over SQS queues with dead-letter handling, a Step Functions saga, and DynamoDB / S3 sinks — the shape most serverless backends converge on.
WeaveKubernetes Cluster Topology
Managed control plane, an application node group and a system node group, with ingress, CoreDNS, monitoring and the CSI driver — plus the registry, database and secret store the pods depend on.
WeaveMicroservices Map with API Gateway & Service Mesh
Eight bounded-context services inside an Istio mesh pool, fronted by an API gateway, wired to Kafka for domain events and to their own datastores — with the mesh control plane drawn as a nested frame.
WeaveMulti-Region Active / Warm-Standby Failover
Route 53 health checks and Global Accelerator in front of two regions: a full active stack in eu-west-1 and a scaled-down warm standby in us-east-1, joined by Aurora Global, S3 CRR and DynamoDB global tables.
WeaveCDN & Edge-Caching Request Path
One request from a browser through anycast DNS, WAF and an edge function to the PoP cache, then the hit / miss branch out to the regional cache and origin — with TTLs, invalidation policy and hit ratio called out.
WeaveZero-Trust Network Access
No network perimeter: identity, device posture, risk and context feed a policy decision point, and an identity-aware proxy enforces per-request access to micro-segmented resources, logging every decision.
WeaveOn-Prem to Cloud Migration
A data centre and an AWS landing zone joined by Direct Connect with a VPN backup, plus the three migration tools that actually move the estate — MGN for VMs, DMS for Oracle, DataSync for the NAS.
WeaveMessage Queue Fan-Out
One publisher, an SNS topic and four filtered SQS subscriptions — plus a separate SNS FIFO topic for the ledger, because a standard topic cannot deliver to a FIFO queue — each with its own consumer, sink, retry policy and shared dead-letter queue that pages on depth.
WeaveHybrid Identity & SSO Flow
On-prem Active Directory synchronised into a cloud IdP, HR as the joiner/mover/leaver source via SCIM, conditional access and MFA in the middle, and SAML / OIDC federation out to every application.
WeaveDFD — Smart Metering (AMI)
Half-hourly meter reads travelling from the home area network through the DCC wide-area network into head-end validation, settlement and billing, with four network segments as trust zones and 9 crossings between them.
Data flow diagramRBD — Data-Centre Power Train
Utility feed backed by a cold-standby generator pair, 2N UPS strings and 2-of-3 PDUs, computing annual system reliability, MTTF and availability for the rack busway.
Reliability block diagramRBD — Dual-Carrier WAN Path
One-month SLA window on a payments WAN path: two independent edge-router-plus-carrier legs with an LTE bearer, a firewall cluster, core fabric and anycast DNS.
Reliability block diagramDSM — Checkout Service Coupling
Sixteen services of a commerce platform taken in the alphabetical order the service registry lists them, where partitioning turns 23 backwards call dependencies into 4 and exposes a five-service checkout core — checkout, orders, inventory, fraud scoring, payments — that no deployment order can untangle.
Design structure matrixDSM — Payments Team Topology
Team DSM of eleven squads in a retail bank's payments division read in inputs-in-columns convention, turning 25 hand-off dependencies listed in org-chart order into a sequence with 3 feedback marks and naming the card/fraud/onboarding/data quartet and the treasury–reporting pair as the groups that need a shared planning cadence.
Design structure matrixArchiMate — Order to Cash, Three Layers
The canonical layered view: a business process served by application services, realized by components, deployed on nodes. Every line is the specific ArchiMate relationship rather than a generic arrow — a component realizes its service and serves the process, which are two different claims that most drawings collapse into one.
ArchiMateArchiMate — Motivation: Drivers, Goals and Requirements
Why the architecture is being changed at all, in the layer most models skip. Stakeholders hold drivers, drivers influence goals, goals are realized by requirements, and requirements are realized by the things the other layers build — the only chain that connects a piece of software back to a reason for it.
ArchiMateArchiMate — Application Cooperation and Data Flow
How five applications actually depend on one another, drawn with flow for what moves and serving for what is used. The distinction is the point: a flow says data travels, a serving says one component needs another to work, and a landscape that draws both as one arrow cannot answer either question.
ArchiMateArchiMate — Technology Deployment, Composition vs Aggregation
A deployment view that keeps the two diamonds apart. A node is COMPOSED OF the parts that cannot exist without it (filled diamond) and AGGREGATES the things it merely collects (hollow diamond) — one attribute apart, the pair most often collapsed, and the collapse changes what the model says about lifecycle and ownership.
ArchiMateArchiMate — One Service, All the Way Down
A single vertical slice from a customer-facing service to the artifact that implements it, which is the view that answers 'what breaks if this server goes down'. Every layer boundary is crossed by realization going up and serving going across, which is the ArchiMate pattern worth learning first.
ArchiMateArchiMate — Specialization and Generic Types
A reference model where the interesting line is specialization — the solid hollow triangle that says one element is a kind of another, and which shares its arrowhead with realization and differs only in whether the line is dashed. Collapsing the two makes the model claim that a subtype implements its supertype, which is a different statement entirely.
ArchiMateArchiMate — Grouping and Location Across Two Regions
Where things run, which is a compliance question before it is an architecture one. Location and grouping are the two elements that belong to no layer, and this model uses them to say which components sit in which jurisdiction and what crosses between them.
ArchiMatePacket — IPv4 Header (RFC 791)
The header every network diagram starts from, drawn at 32 bits a word in RFC bit order with the absolute bit indices on the ruler. Complete: every bit of the five fixed words is claimed, so the engine reports no gaps and the reader can trust that the layout is the whole layout.
Packet & bit fieldsPacket — TCP Header (RFC 9293)
Twenty bytes of TCP with each control flag on its own bit, which is the part a prose description always compresses into 'flags' and the part anyone reading a capture actually needs. Written with run-length fields after the first word to show the two notations mixing.
Packet & bit fieldsPacket — Ethernet II Frame Header
Two MAC addresses and an EtherType, which is the smallest useful demonstration of a field that wraps across word boundaries: a 48-bit address on a 32-bit word does not fit in one row and is drawn split rather than flagged, because wrapping is the layout working and not a defect. It also declares no extent, so the engine says the trailing sixteen bits of the last word are outside the layout rather than unallocated inside it — two states that must not look the same.
Packet & bit fieldsPacket — UDP Header, Eight Bytes
The whole of UDP in two words, and the clearest example of the run-length form: four consecutive sixteen-bit fields written as `+16:` rather than as absolute ranges, with the cursor doing the arithmetic so a later insertion does not require renumbering everything after it.
Packet & bit fieldsPacket — 32-bit Control Register (datasheet order)
A peripheral control register in LSB-first order, which is how every datasheet in the world numbers bits and the opposite of the RFC convention the protocol templates use. Reserved bits are declared with their required value rather than left out, so the layout has no unclaimed holes and firmware written from it will not leave a reserved bit floating.
Packet & bit fieldsPacket — 16-bit Status Register with Read-Only Flags
A narrower word width, which is the setting people forget exists and then draw a 16-bit register on a 32-bit grid. Sixteen bits a word, LSB order, every bit accounted for — including the two reserved runs, because a reserved bit that is simply absent from the drawing is indistinguishable from one nobody thought about.
Packet & bit fieldsPacket — DNS Message Header (RFC 1035)
Twelve bytes with a four-bit opcode and a four-bit response code packed either side of five single-bit flags, which is the layout most often drawn wrong because the flag byte is easier to describe in prose than to lay out. Complete over three 32-bit words.
Packet & bit fieldsPacket — IPv6 Fixed Header, Forty Bytes
Ten words with two 128-bit addresses, which is the case that makes the wrapping question unavoidable: each address is four whole words and is drawn as such. Useful as a starting point for extension-header diagrams, where the fixed part above stays and the rest changes.
Packet & bit fieldsPacket — Deliberately Wrong: Two Fields Claiming One Bit
A teaching artefact with two overlaps in it: `Loopback` and `Mode` both claim bit 5, and `Mode` and `Speed` both claim bits 6 to 8. The drawing of that is indistinguishable from a correct one, which is why the engine computes each overlap, hatches it and names both under the figure. Open this one to see what an overlap finding reads like before you meet one in your own register map.
Packet & bit fieldsPacket — Deliberately Wrong: Bits Nobody Claimed
The second teaching artefact. Bits 12 to 19 of a declared two-word layout belong to no field, and the difference between 'reserved' and 'nobody thought about it' is the whole of what a register map is for. The engine marks the run and says how wide it is, rather than drawing a tidy diagram over a hole.
Packet & bit fieldsAWS — Three-Tier Web Application, Multi-AZ
The reference architecture, drawn correctly and reported clean: a public load balancer, application servers in private subnets across two availability zones, and the database isolated with a standby in the other zone. Copy this one. Every check runs and finds nothing, which the engine states rather than implies.
Cloud architectureTeaching Case — A Database in a Public Subnet
Deliberately wrong, and the drawing of it is indistinguishable from a correct one — which is the point. The database sits in a subnet the document itself declares public, and the traffic path from the internet reaches it without passing through anything that terminates or filters. The engine names both, with the path it walked, so a reader can check the accusation rather than take it.
Cloud architectureTeaching Case — "Highly Available" in One Zone
Three application servers and a database, every one of them marked highly available, all of them inside a single availability zone. The count is the trap: `count 3` looks like redundancy and is not, because three instances in one zone is one zone. The engine says exactly that, in those words.
Cloud architectureTeaching Case — What "I Could Not Check That" Looks Like
The most important template in this set, and nothing in it is wrong. It is an ordinary, sensible diagram that declares no availability zones — which is what almost every real cloud diagram looks like. The availability check therefore cannot run at all, and the engine says so plainly instead of reporting a pass. That state is the one most tools never show anyone.
Cloud architectureAWS — Serverless API, Edge to Table
A serverless request path with no servers in it: CDN, API gateway, functions, a document store and an object store, with a queue for the asynchronous half. Reports clean — and shows the async edge style, which is drawn differently from request traffic because a queue between two services is a different claim from a call.
Cloud architectureGoogle Cloud — GKE Microservices with Managed Data
A Kubernetes cluster on GKE with its namespaces drawn as real containers, an ingress terminating outside traffic, and the stateful half deliberately outside the cluster in managed services. Reports clean. The pattern worth copying is that last part: the databases are managed, not StatefulSets, and the diagram makes that visible.
Cloud architectureAzure — Hub-and-Spoke Landing Zone
The enterprise pattern: a hub virtual network carrying the shared firewall, bastion and gateway, with workload spokes peered to it. Reports clean. Note the boundary edges — traffic that crosses from one virtual network to another names the gateway it crosses at, which is what stops the engine reporting an unexplained boundary crossing.
Cloud architectureHybrid — On-Premises to Cloud Over a VPN
A migration-shaped diagram: a mainframe and a file server still on-premises, a VPN into the cloud, and a third-party payment provider outside both. Reports clean. It is the clearest demonstration of what the boundary check is for — every edge that leaves one network for another names the gateway it goes through.
Cloud architectureKubernetes — Workloads, Storage and Config
A cluster drawn in pure Kubernetes objects, with the distinction the notation exists to make visible: a Deployment is stateless and replicated, a StatefulSet has a volume claim behind it, and the two must not be drawn the same way. Reports clean.
Cloud architectureTeaching Case — Boxes Nobody Connected, Words Nobody Knows
Two quieter failures, side by side. A resource that appears in no edge is a box somebody drew and never wired — legitimate for a legend, a real omission everywhere else — and a type word this engine's vocabulary does not carry is reported as a GAP in the vocabulary rather than as a mistake by the author. The difference between those two sentences is the difference between blaming the reader and blaming the tool.
Cloud architectureProvider-Agnostic — One Architecture, No Vendor Names
The same shape written entirely in the generic vocabulary, which is what a design document wants before the cloud has been chosen and what a comparison across two clouds needs. Reports clean. Categories still colour the boxes, so the figure reads by function rather than by vendor — which is the question anyone looking at it is trying to answer.
Cloud architecture