--- title: "Architecture diagram template – Display.dev" description: "An architecture overview as a single HTML file – inline SVG diagram, component table, and the decisions worth knowing. Publish it to a URL in one click, no account." --- # Architecture diagram template An architecture overview as a single HTML file – inline SVG diagram, component table, and the decisions worth knowing. Publish it to a URL in one click, no account. - Format: HTML - Detail page: https://display.dev/templates/architecture-diagram - Raw template file: https://display.dev/template-sources/architecture-diagram.html - One-click anonymous publish (no account): POST the file to https://api.display.dev/v1/public/artifacts as multipart/form-data (`file` field) ## Agent prompt Document this system's architecture on display.dev. Fetch https://display.dev/template-sources/architecture-diagram.html as the starting point – an inline SVG diagram (edit the nodes and edges in the markup), a component table with responsibilities, and a "decisions worth knowing" list. Map the real services from the codebase and deploy config; mark the hot path; keep the file self-contained (inline SVG and CSS, no diagram libraries, no external requests). Publish it with the display.dev MCP publish tool if connected. Otherwise POST the file to https://api.display.dev/v1/public/artifacts as multipart/form-data (`file` field, optional `name`) – no account needed. You'll get back `previewUrl` (the link to share) and `claimUrl` (one-shot link to take ownership). Reply with both. ## What this template is for The architecture page every new engineer asks for: one diagram, a table of what each component actually does, and the three decisions that explain why the system looks like this. The diagram is inline SVG – nodes and edges are plain markup an agent can edit, no diagram tool, no export step, no stale PNG. The green highlight marks the hot path, because the first question about any architecture is "which parts can't fail?" ## How teams use it - **Generated from the codebase.** The agent reads the services and deploy config, drafts the diagram and table, and flags what it couldn't verify; an engineer confirms the edges. - **Kept current at one URL.** When topology changes, the agent updates the SVG and publishes a new version – the link in your onboarding doc never goes stale, and version history shows how the system evolved. - **Reviewed where it's read.** "This edge is gone" lands as an inline comment on the diagram, not a message in a channel. ## Template source ````html Architecture overview – order platform

Architecture overview – order platform

Current production topology · last verified 21 July 2026 · owner: platform team · green marks the checkout hot path

Components

Component	Responsibility	Notes
API gateway	Auth, rate limiting, routing	Stateless; scales horizontally
Order service	Checkout, order lifecycle	The hot path – p99 budget 250 ms
Catalog service	Product reads	95% cache hit rate; safe to degrade
Postgres	System of record for orders	Single writer; 7-day PITR window
Event queue	Order events fan-out	At-least-once; consumers are idempotent
Workers	Billing, notifications	Retry with backoff; dead-letter after 5

Decisions worth knowing

Catalog degrades before checkout does – load-shedding drops browse traffic first.
Billing is queue-consumer only: nothing on the checkout path waits on it.
Dashed edge = catalog cache warms from order events, eventual by design.

````