Components & ports

Components are the building blocks you place on the canvas. Ports are the labeled connection points on each component — they decide what can plug into what.

The component library

The Components panel groups building blocks by what they do. Most components are executable — they take part when you run a scenario. The two canvas helpers are visual only — they organize the picture and never affect behavior.

Sources & triggers

Actor / client	The person or system that starts things off. It sends a request and waits for the response.
Scheduler / trigger	Starts work on a schedule instead of on demand — a bounded number of ticks at a fixed interval, like a cron job or nightly batch.

Routing & compute

Gateway / router	Checks incoming requests and routes each one to the right place using ordered rules.
Service / function	Does a piece of work. It can call other components, wait for their answers, and publish events.
Transform	Reshapes or validates data as it passes through, without any custom code.

Data & state

Cache / key-value store	Remembers values for fast lookup. Entries can expire after a time you set (TTL).
Database	Stores records that your scenario can read, insert, update, and delete.
Object storage	Represents files, images, or exports that can be stored, found, or deleted. A run passes a reference to the object rather than the file itself.

Messaging

Queue	Holds messages until a consumer picks them up — with retries and a dead-letter path for messages that keep failing.
Topic / event bus	Broadcasts one published event to every subscriber. Each subscription receives its own copy, so many parts of the system can react to the same event.

Control & orchestration

Timer / delay	Waits for an amount of time, then continues. Useful for modeling delays.
Join / aggregator	Waits until enough related branches have arrived — all of them, any one, or a number you choose — then continues once.
Workflow / saga	Runs a sequence of steps in order — one step per outgoing connection — and answers its caller once every step has completed.

Integration & boundaries

External dependency / terminal	Stands in for anything outside your diagram — a payment provider, a third-party API. After its configured latency, it replies with success or raises the named failure.
Diagram link / boundary	Points to another diagram in the workspace. You can open the linked diagram and return; during a run, the link behaves as a boundary rather than running the second diagram.

Canvas helpers (visual only)

Group / boundary	A labeled box for organizing the picture: teams, regions, trust zones. It never executes.
Note / legend	Plain-text notes on the canvas. Great for explaining a diagram to teammates.

Tip

Every component is covered in depth — ports, settings, and a worked use case with a diagram — in the Component reference.

What ports are

Every executable component has ports: small squares on its edges. Input ports sit on the left and receive things; output ports sit on the right and send things. Connections always run from an output port to an input port — that is how requests, responses, and messages know which way to flow.

A Service component. Inputs on the left receive requests and results; outputs on the right send responses and downstream calls.

Each port has a clear purpose. It knows what kind of thing it sends or receives, and the editor only lets you connect ports that match. Hover any port to see its details, or open the Ports tab in the Inspector for the full list on the selected component.

How ports know what can connect

Each port has a direction — input or output — and says what kind of information it carries. Both ends of a connection must agree. The port's purpose also decides the connection type you see on the arrow.

Message kind	What travels through
request	A question on its way to whoever will answer it.
response	The answer coming back to the component that asked.
command	An instruction to do something with state — write to a database, put an object, look up a cache key.
record	Data being handed over: a database result, a cache hit, the payload flowing through a transform.
event	A fire-and-forget notification: something happened, and whoever cares can react.
control	A signal that steers behavior rather than carrying business data — like starting a timer.
objectRef	A reference to a stored object — its key and metadata, never the raw bytes.

Roles come in natural pairs. Request ports talk to request ports and response ports answer them — that’s a synchronous call. Read, write, ack, and nack ports form data-access conversations with stores. Enqueue and consume ports pass fire-and-forget messages through queues. Publish and subscribe ports fan an event out through a topic. Join ports collect branches at a barrier. Control ports carry steering signals, and terminal ports end a story — an error route or a dead-letter path.

A few ports worth knowing

You don’t need to memorize every port — hovering tells you what each one does. But a few come up all the time:

Component	Ports you’ll use
Actor / client	request out to start a journey, response in to receive the answer, event out for fire-and-forget messages.
Service / function	request in and response for the work it serves; call and return for calling other components; publish event for fire-and-forget messages.
Cache	lookup in, then hit or miss out — so cache hits and misses can take different paths in your diagram.
Queue	enqueue in, dispatch out to one consumer, ACK/NACK in for the consumer’s verdict, and DLQ out for dead letters.
Topic / event bus	publish in receives the event; deliver out fans it to subscribers — every connection from that one port is a separate subscription.
Join / aggregator	branch in collects arrivals from parallel paths; joined out continues once the join policy is satisfied.

Tip

Some ports have limits. A queue’s dispatch port accepts one connection, because the queue models a single consumer slot — while a topic’s deliver port accepts many, one per subscription. The editor tells you when a port is full.