Mermaid sequentiediagram-editor
Een sequentiediagram laat zien wie met wie praat en in welke volgorde. Het past wanneer de uitwisseling van berichten tussen meerdere partijen het onderwerp is — authenticatie, betalen, koppelingen tussen diensten. Is er maar één deelnemer en gaat het om de vertakkingen, dan zegt een stroomdiagram hetzelfde met minder ruis.
Een iDEAL-betaling met terugkoppeling
De waarde van dit diagram zit in het `alt`-blok: het laat zien dat de betaling twee verschillende afloopen heeft en dat de webshop het resultaat niet van de klant hoort maar van de betaaldienst. Let ook op de laatste pijl: de bevestiging komt asynchroon terug, los van de browser van de klant. Precies dat maakt een sequentiediagram zichtbaar en verstopt een stroomdiagram.
sequenceDiagram
autonumber
participant K as Klant
participant W as Webshop
participant P as Betaaldienst
participant B as Bank van de klant
K->>W: Bevestig de bestelling
W->>P: Start de transactie
P-->>W: Betaal-URL
W-->>K: Stuur door naar de bank
K->>B: Kies rekening en bevestig
alt Betaling geslaagd
B-->>P: Geslaagd
P-->>W: Statusmelding
W->>W: Markeer als betaald
else Geannuleerd of verlopen
B-->>P: Geannuleerd
P-->>W: Statusmelding
W->>W: Houd de bestelling open
end
W-->>K: Toon de bevestigingspaginaUitgewerkte voorbeelden
1. Twee deelnemers en één bericht
`->>` is de pijl met gevulde punt, oftewel een aanroep. `-->>` is gestippeld en betekent het antwoord. Dat paar volstaat in de meeste diagrammen.
sequenceDiagram
Client->>API: Maak de bestelling
API-->>Client: 201 Created2. Aliassen voor lange namen
`participant X as Lange naam` geeft een korte id om te typen en een leesbare naam om te lezen. Deelnemers vooraan declareren legt ook hun volgorde in de tekening vast; zonder declaratie bepaalt de eerste vermelding die.
sequenceDiagram
participant B as Browser
participant O as Besteldienst
participant V as Voorraaddienst
B->>O: POST /bestellingen
O->>V: Reserveer de artikelen
V-->>O: Reservering bevestigd
O-->>B: 201 Created3. Activaties en aanroepen naar zichzelf
`activate` en `deactivate` tekenen een balk die laat zien dat een deelnemer bezig is. De achtervoegsels `+` en `-` op de pijl doen hetzelfde met minder typewerk. Een pijl van een deelnemer naar zichzelf betekent intern werk.
sequenceDiagram
participant A as API
participant D as Database
Client->>+A: GET /factuur/42
A->>+D: SELECT factuur
D-->>-A: Rij gevonden
A->>A: Bereken de btw
A-->>-Client: 200 OK4. Alternatieven, opties en lussen
`alt`/`else` zijn elkaar uitsluitende paden, `opt` is een blok dat er niet hoeft te zijn en `loop` is een herhaling. Alle drie sluiten af met `end`, en dat vergeten is de meestgemaakte fout van dit type.
sequenceDiagram
participant G as Gebruiker
participant A as API
participant M as Maildienst
G->>A: Vraag een account aan
alt Adres al geregistreerd
A-->>G: 409 Conflict
else Adres nog vrij
A-->>G: 201 Created
A->>M: Stuur de verificatie
loop Maximaal 3 pogingen
M->>M: Herhaal bij mislukte verzending
end
end
opt Gebruiker wil de nieuwsbrief
A->>M: Voeg toe aan de lijst
end5. Notities en gelijktijdige verwerking
`par` toont takken die tegelijk lopen, iets wat een stroomdiagram hooguit kan suggereren maar nooit uitspreekt. Notities zijn de juiste plek voor het detail dat niet in een berichtlabel past.
sequenceDiagram
participant O as Besteldienst
participant F as Facturatie
participant L as Logistiek
Note over O: De bestelling is al betaald
par Meld het aan facturatie
O->>F: Maak de factuur
F-->>O: Factuur 2026/0431
and Meld het aan logistiek
O->>L: Bereid de zending voor
L-->>O: Vrachtbrief aangemaakt
end
Note over F,L: Elk gaat in zijn eigen tempo verderOverzicht van de sequentiediagram-syntaxis
Wat je moet onthouden zijn de pijlen, en die horen uitsluitend bij dit type: de `-->` uit het stroomdiagram betekent hier iets anders, en de `->>` van hier is een fout in het klassendiagram.
| Syntaxis | Betekenis |
|---|---|
| sequenceDiagram | Opent het diagram. Hoofdlettergevoelig: `sequencediagram` werkt niet. |
| participant A | Declareert een deelnemer en legt zijn positie vast. |
| participant A as Naam | Korte id met leesbare naam. |
| actor A | Als participant, maar tekent een poppetje. |
| A->>B: tekst | Bericht met gevulde punt — een aanroep. |
| A-->>B: tekst | Stippellijn — een antwoord. |
| A-)B: tekst | Open punt — asynchroon bericht. |
| A->>A: tekst | Deelnemer roept zichzelf aan. |
| activate A / deactivate A | Markeert de periode waarin A bezig is. |
| A->>+B: / B-->>-A: | Hetzelfde in korte vorm, direct op de pijl. |
| alt voorwaarde ... else ... end | Elkaar uitsluitende paden. |
| opt voorwaarde ... end | Blok dat er niet hoeft te zijn. |
| loop tekst ... end | Herhaling. |
| par ... and ... end | Gelijktijdige takken. |
| Note over A,B: tekst | Notitie boven één of meer deelnemers. `Note left of` en `Note right of` bestaan ook. |
| autonumber | Nummert de berichten automatisch. |
De zes fouten die een sequentiediagram slopen
Nagemaakt op Mermaid 11.12.2. De eerste is veruit de meest voorkomende, en de melding erbij hoort tot de slechtste aanwijzingen waar het probleem zit.
Wat je ziet
Parse error die naar de laatste regel van het diagram wijst
Waarom
Een blok dat geopend is en nooit gesloten. `alt`, `opt`, `loop` en `par` willen elk hun eigen `end`. Mermaid meldt de fout waar de invoer op is, dus het regelnummer wijst naar het einde van het bestand en niet naar het openstaande blok. Bij twee geneste blokken wordt dat echt lastig te vinden.
Oplossing
Tel de geopende blokken en de `end`s die je geschreven hebt. Wijst de fout naar de laatste regel, dan is dit het bijna altijd.
sequenceDiagram
Client->>API: Verzoek
alt Alles in orde
API-->>Client: 200 OKsequenceDiagram
Client->>API: Verzoek
alt Alles in orde
API-->>Client: 200 OK
endWat je ziet
No diagram type detected matching given configuration
Waarom
Verkeerde hoofdletters in het sleutelwoord. `sequenceDiagram` werkt; `sequencediagram` en `SequenceDiagram` niet. Mermaid is hoofdlettergevoelig in al zijn sleutelwoorden.
Oplossing
Hoofdletter D, de rest klein.
sequencediagram
Client->>API: HallosequenceDiagram
Client->>API: HalloWat je ziet
Het tekent, maar het bericht komt zonder label uit
Waarom
Er ontbreekt tekst na de dubbele punt. Gemeten: Mermaid weigert het niet — het tekent het bericht met een leeg label, en de pijl blijft zonder uitleg staan. Wat wél faalt is de dubbele punt helemaal weglaten: `Client->>API` alleen geeft `Expecting 'TXT', got 'NEWLINE'`. De dubbele punt is dus verplicht en de tekst niet, precies andersom dan je zou aannemen.
Oplossing
Schrijf iets na de dubbele punt, al is het één woord. Een pijl zonder label is bijna nooit wat je bedoelde.
sequenceDiagram
Client->>API:
API-->>Client: 200sequenceDiagram
Client->>API: Maak de bestelling
API-->>Client: 200Wat je ziet
Parse error na een `alt` met een lange voorwaarde
Waarom
Een regelafbreking binnen de voorwaarde van een blok. De voorwaarde van `alt`, `opt` of `loop` moet op één regel passen; breek je hem af, dan wordt de tweede helft als bericht gelezen en past nergens.
Oplossing
Houd de voorwaarde op één regel. Is hij te lang, kort hem in en verplaats het detail naar een notitie.
sequenceDiagram
alt De klant heeft voldoende
saldo op de rekening
A-->>B: OK
endsequenceDiagram
alt De klant heeft voldoende saldo
A-->>B: OK
end
Note over A,B: Saldo wordt getoetst aan de daglimietWat je ziet
Het tekent, maar er verschijnt een deelnemer die je niet gedeclareerd hebt
Waarom
Een tikfout in een deelnemersnaam. Mermaid maakt de deelnemer aan zodra hij een naam voor het eerst tegenkomt, dus `Betaaldienst` en `Betaaldiensr` zijn twee losse kolommen en niets waarschuwt je. In het Nederlands is de lange samenstelling de meest voorkomende bron: hoe langer het woord, hoe makkelijker er één letter in verschuift.
Oplossing
Declareer de deelnemers vooraan met `participant`. Dat voorkomt de tikfout niet, maar maakt zichtbaar welke namen de juiste zijn, en de kolom te veel valt meteen op.
sequenceDiagram
Webshop->>Betaaldienst: Start de transactie
Betaaldiensr-->>Webshop: StatusmeldingsequenceDiagram
participant W as Webshop
participant P as Betaaldienst
W->>P: Start de transactie
P-->>W: StatusmeldingWat je ziet
Het tekent, maar de kolomvolgorde is niet die je bedoelde
Waarom
Je hebt de deelnemers niet gedeclareerd. Zonder declaratie bepaalt de eerste vermelding van elke naam de volgorde, dus een bericht dat je bovenaan het diagram toevoegt kan alle kolommen herschikken en de pijlen over elkaar heen laten lopen. Het diagram blijft correct, maar leest een stuk slechter.
Oplossing
Declareer alle deelnemers in de kop, in de volgorde waarin je ze wilt zien.
sequenceDiagram
Bank-->>Betaaldienst: Geslaagd
Klant->>Webshop: Bevestig de bestelling
Webshop->>Betaaldienst: Start de transactiesequenceDiagram
participant Klant
participant Webshop
participant Betaaldienst
participant Bank
Klant->>Webshop: Bevestig de bestelling
Webshop->>Betaaldienst: Start de transactie
Betaaldienst->>Bank: Stuur door
Bank-->>Betaaldienst: GeslaagdAantekeningen over het tekenen
Gemeten op Mermaid 11.12.2, de versie die deze site gebruikt. Het sequentiediagram gedraagt zich op twee concrete punten anders dan de rest.
De breedte bepalen de deelnemers, niet de berichten
Gemeten: twee deelnemers geven een viewBox van 450 pixels breed, zes geven er 1250, dus ongeveer 200 pixels per extra kolom, ongeacht wat er in de berichten staat. Berichten voegen alleen hoogte toe, ongeveer 46 pixels per stuk. Met één voorbehoud: is een berichtlabel breder dan de minimale kolombreedte, dan verbreedt het het diagram wel degelijk — hetzelfde paar deelnemers ging van 450 naar 603 pixels puur doordat de tekst van één bericht langer werd. Nederlandse labels zijn de langste die hier gemeten zijn, dus dat gebeurt eerder dan in het Engels.
Het enige type met een negatieve viewBox-oorsprong
Sequentiediagrammen komen eruit met een viewBox die begint op `-50 -10` in plaats van `0 0`. Dat is geen defect: Mermaid reserveert die marge voor de kaders van de deelnemers. Het telt alleen als je de SVG met eigen gereedschap verwerkt, want elke berekening die van oorsprong nul uitgaat, kapt de eerste kolom af.
Hier klopt de PNG-export wel
Anders dan het stroomdiagram en de klassen-, toestands- en ER-diagrammen tekent het sequentiediagram zijn labels als gewone SVG-tekst en niet binnen een `<foreignObject>`. Daardoor laat het zich rechtstreeks rasteren: de geëxporteerde PNG komt overeen met het scherm, zonder tussentijdse hertekening en zonder verschuiving in de zetwijze.
Een gedeclareerde en ongebruikte deelnemer wordt toch getekend
Een `participant` die geen enkel bericht verstuurt of ontvangt, verschijnt in het diagram met een lege kolom. Soms is dat bedoeld, om iemand te tonen die bestaat maar niet aan deze stroom meedoet. Vaker is het het restant van een deelnemer wiens laatste bericht is weggehaald zonder de declaratie mee te verwijderen.
Het thema verandert de kleuren, nooit de geometrie
Hetzelfde diagram in het lichte en het donkere thema geeft een identieke viewBox, dus kolommen schuiven niet en blokken veranderen niet van formaat als het thema wisselt.
Wanneer een ander diagram beter past
Is er maar één deelnemer, dan valt er geen volgorde te tonen. Een diagram met één kolom en pijlen naar zichzelf is een stroomdiagram dat ongemakkelijk is opgeschreven.
Wil je de toestanden beschrijven die iets doorloopt en niet het gesprek tussen partijen, gebruik dan een toestandsdiagram. Het signaal is duidelijk: schrijf je keer op keer hetzelfde bericht met een andere voorwaarde, dan heb je een toestandsmachine voor je.
En loopt de uitwisseling boven de vijftien berichten, splits hem dan. Een sequentiediagram met zestig berichten is technisch correct en voor mensen onbruikbaar; het leest vrijwel altijd beter als drie diagrammen, één per fase, verbonden met een notitie.
Andere diagramtypen
Geschreven door Dominik Malsch · Laatst bijgewerkt: