System architecture diagrams
The map of your backend: which services exist, how they talk, and where data and events flow. In Skeema this diagram is the source of truth that everything else derives from.
What is a system architecture diagram?
A system architecture diagram shows the major components of a software system and the connections between them. Unlike a UML class diagram (which describes code) or a network diagram (which describes hardware), an architecture diagram works at the level of services and infrastructure: an API gateway, an auth service, a database, a message queue. Its job is to answer “how does a request flow through this system, and what does each part do?”
A good architecture diagram makes three things obvious: the components, the direction of communication between them, and which calls are synchronous (the caller waits) versus asynchronous (fire-and-forget via a queue or event bus).
When to use one
- •Designing a new system and reasoning about responsibilities and boundaries.
- •Onboarding engineers — a single picture beats a wiki of prose.
- •Reviewing a design for single points of failure, missing caches, or synchronous calls that should be async.
- •Estimating scale and cost before you write code.
Anatomy in Skeema
Skeema classifies every node into a type, shown as a colored chip on the card:
| Node type | Represents | Examples |
|---|---|---|
CLIENT | Entry points that originate requests | Web app, mobile app, CLI |
GATEWAY | Routing / edge layer | API gateway, load balancer, BFF |
SERVICE | Business logic | Auth, payments, search, AI worker |
DATABASE | Durable storage | Postgres, MySQL, DynamoDB |
QUEUE | Async messaging | Kafka, SQS, RabbitMQ |
CACHE | Low-latency reads / sessions | Redis, Memcached |
EXTERNAL | Third-party dependency | Stripe, OpenAI, Twilio |
Edges: sync vs async
A solid edge is a synchronous call — the caller blocks until it gets a response, so its latency adds to the request path. A dashed, animated edge is asynchronous — the producer publishes an event and moves on, decoupling the two services. Skeema auto-detects async edges from labels (publishes, event, kafka) and draws them differently because the distinction changes how the system behaves under load.
Domain zones
Related nodes are grouped into labeled zones (Clients, Gateway, Core Services, Data & Events). Skeema uses a two-pass dagre layout — laying out nodes within each zone first, then the zones relative to one another — so even large diagrams stay readable.
Generating & editing
- •Prompt — describe the system; include scale to auto-add load balancers, replicas, and caches.
- •Code → diagram — paste a service file or repo structure to derive the graph.
- •Edit mode — ask for a change in plain English; Skeema smart-merges it, preserving your layout.
- •Manual — drag from the node palette; connect handles; edit labels and technologies in the side panel.
From diagram to everything else
Once the architecture exists, derive an ER schema from a database node, a sequence flow for a request path, or API routes for a service — all linked back by lineage. Run a load simulation or cost estimate directly on the diagram.
- ✓Architecture diagrams model services and infrastructure, not code or hardware.
- ✓Sync (solid) vs async (dashed) edges is the most important distinction — it drives load behavior.
- ✓Skeema types every node and groups them into zones for readability.
- ✓The architecture is the root from which ER, sequence, and code are derived.