Mermaid सीक्वेंस आरेख एडिटर
सीक्वेंस आरेख दिखाता है कि कौन किससे और किस क्रम में बात करता है। यह तब ठीक है जब मुख्य बात कई पक्षों के बीच संदेशों का आदान-प्रदान हो — प्रमाणीकरण, भुगतान, सेवाओं के बीच जोड़। अगर भागीदार सिर्फ़ एक है और असल बात शाखाएँ हैं, तो फ़्लोचार्ट वही बात कम शोर के साथ कहता है।
यूपीआई से भुगतान
इस आरेख की क़ीमत `alt` खंड में है: वह दिखाता है कि लेनदेन के दो अलग अंत हैं, और यह भी कि दुकानदार को नतीजा ग्राहक से नहीं बल्कि भुगतान-नेटवर्क से मिलता है। यह भी देखें कि भागीदारों की पहचान देवनागरी में है — सीक्वेंस आरेख में यह पूरी तरह चलता है, और यही इसे हिंदी के लिए सबसे उदार प्रकार बनाता है।
sequenceDiagram
autonumber
participant ग as ग्राहक
participant ऐप as भुगतान ऐप
participant नेट as भुगतान नेटवर्क
participant बैंक as ग्राहक का बैंक
ग->>ऐप: दुकान का क्यूआर स्कैन करें
ऐप->>नेट: संग्रह अनुरोध बनाएँ
नेट->>बैंक: डेबिट के लिए भेजें
बैंक-->>ऐप: पिन माँगें
ग->>ऐप: पिन डालें
alt शेष राशि पर्याप्त और सीमा के भीतर
बैंक->>नेट: डेबिट सफल
नेट-->>ऐप: सफलता की सूचना
ऐप-->>ग: रसीद दिखाएँ
else शेष राशि कम या सीमा पार
बैंक->>नेट: लेनदेन अस्वीकृत
नेट-->>ऐप: विफलता की सूचना
ऐप-->>ग: कारण दिखाएँ
end
नेट->>नेट: निपटान के लिए क़तार में डालेंहल किए गए उदाहरण
1. दो भागीदार और एक संदेश
`->>` भरी नोक वाला तीर है, यानी एक कॉल। `-->>` बिंदुदार है और उत्तर बताता है। ज़्यादातर आरेखों में यही जोड़ा काफ़ी है।
sequenceDiagram
क्लाइंट->>एपीआई: ऑर्डर बनाएँ
एपीआई-->>क्लाइंट: 201 Created2. लंबे नामों के लिए उपनाम
`participant X as लंबा नाम` लिखने के लिए छोटी पहचान और पढ़ने के लिए साफ़ नाम देता है। भागीदारों को शुरू में घोषित करना चित्र में उनके स्तंभों का क्रम भी तय कर देता है; घोषणा न हो तो क्रम पहली बार आने से तय होता है।
sequenceDiagram
participant ब as ब्राउज़र
participant ऑ as ऑर्डर सेवा
participant गो as गोदाम सेवा
ब->>ऑ: POST /orders
ऑ->>गो: सामान आरक्षित करें
गो-->>ऑ: आरक्षण की पुष्टि
ऑ-->>ब: 201 Created3. सक्रियण और ख़ुद को कॉल
`activate` और `deactivate` एक पट्टी बनाते हैं जो दिखाती है कि भागीदार काम कर रहा है। तीर पर लगे `+` और `-` वही काम कम लिखाई में करते हैं। भागीदार से उसी की ओर जाता तीर भीतरी काम बताता है।
sequenceDiagram
participant ए as एपीआई
participant डी as डेटाबेस
क्लाइंट->>+ए: GET /invoice/42
ए->>+डी: SELECT invoice
डी-->>-ए: पंक्ति मिली
ए->>ए: जीएसटी जोड़ें
ए-->>-क्लाइंट: 200 OK4. विकल्प, वैकल्पिक खंड और चक्र
`alt`/`else` परस्पर अपवर्जी रास्ते हैं, `opt` वह खंड है जो हो भी सकता है और नहीं भी, और `loop` दोहराव है। तीनों `end` से बंद होते हैं, और उसे भूलना इस प्रकार की सबसे आम ग़लती है।
sequenceDiagram
participant उ as उपयोगकर्ता
participant ए as एपीआई
participant मे as मेल सेवा
उ->>ए: खाता खोलने का अनुरोध
alt पता पहले से पंजीकृत
ए-->>उ: 409 Conflict
else पता उपलब्ध
ए-->>उ: 201 Created
ए->>मे: सत्यापन मेल भेजें
loop अधिकतम 3 प्रयास
मे->>मे: विफल होने पर फिर भेजें
end
end
opt उपयोगकर्ता समाचार-पत्र चाहता है
ए->>मे: सूची में जोड़ें
end5. टिप्पणियाँ और समांतर काम
`par` उन शाखाओं को दिखाता है जो एक ही समय चलती हैं, जिसे फ़्लोचार्ट सिर्फ़ इशारे में कह सकता है, कभी साफ़ नहीं कहता। और टिप्पणी उस ब्योरे की सही जगह है जो संदेश के लेबल में नहीं समाता।
sequenceDiagram
participant ऑ as ऑर्डर सेवा
participant बि as बिलिंग
participant लॉ as लॉजिस्टिक्स
Note over ऑ: ऑर्डर का भुगतान हो चुका है
par बिलिंग को बताएँ
ऑ->>बि: जीएसटी चालान जारी करें
बि-->>ऑ: चालान 2026/0431
and लॉजिस्टिक्स को बताएँ
ऑ->>लॉ: शिपमेंट तैयार करें
लॉ-->>ऑ: ट्रैकिंग नंबर बना
end
Note over बि,लॉ: दोनों अपनी रफ़्तार से चलते हैंसीक्वेंस आरेख सिंटैक्स का सार
याद रखने लायक तीर हैं, और वे सिर्फ़ इसी प्रकार के हैं: फ़्लोचार्ट का `-->` यहाँ कुछ और मतलब रखता है, और यहाँ का `->>` क्लास आरेख में ग़लती है।
| सिंटैक्स | अर्थ |
|---|---|
| sequenceDiagram | आरेख खोलता है। बड़े-छोटे अक्षरों के प्रति संवेदनशील: `sequencediagram` नहीं चलता। |
| participant A | भागीदार घोषित करता है और उसकी जगह तय करता है। |
| participant A as नाम | छोटी पहचान के साथ पढ़ने लायक नाम। |
| actor A | participant जैसा, पर आदमी की आकृति बनाता है। |
| A->>B: पाठ | भरी नोक वाला संदेश — एक कॉल। |
| A-->>B: पाठ | बिंदुदार रेखा — एक उत्तर। |
| A-)B: पाठ | खुली नोक — अतुल्यकालिक संदेश। |
| A->>A: पाठ | भागीदार ख़ुद को कॉल करता है। |
| activate A / deactivate A | वह अवधि चिह्नित करता है जब A काम कर रहा है। |
| A->>+B: / B-->>-A: | वही बात, तीर पर ही संक्षिप्त रूप में। |
| alt शर्त ... else ... end | परस्पर अपवर्जी रास्ते। |
| opt शर्त ... end | वह खंड जो हो भी सकता है और नहीं भी। |
| loop पाठ ... end | दोहराव। |
| par ... and ... end | समांतर शाखाएँ। |
| Note over A,B: पाठ | एक या कई भागीदारों के ऊपर टिप्पणी। `Note left of` और `Note right of` भी हैं। |
| autonumber | संदेशों को अपने आप क्रमांक देता है। |
वे छह ग़लतियाँ जो सीक्वेंस आरेख को तोड़ती हैं
Mermaid 11.12.2 पर दोबारा बनाई गईं। पहली कहीं ज़्यादा बार होती है, और उसका संदेश यह बताने में सबसे ख़राब है कि समस्या कहाँ है।
आपको क्या दिखता है
Parse error जो आरेख की आख़िरी पंक्ति बताती है
क्यों
कोई खंड खुला और कभी बंद नहीं हुआ। `alt`, `opt`, `loop` और `par` — हर एक अपना `end` माँगता है। Mermaid त्रुटि वहाँ बताता है जहाँ उसका इनपुट ख़त्म होता है, इसलिए पंक्ति-संख्या फ़ाइल का अंत बताती है, खुला खंड नहीं। दो खंड एक-दूसरे के भीतर हों तो इसे ढूँढ़ना सचमुच मुश्किल हो जाता है।
समाधान
खुले खंड और लिखे हुए `end` गिन लें। अगर त्रुटि आख़िरी पंक्ति बताती है तो लगभग हमेशा यही वजह होती है।
sequenceDiagram
क्लाइंट->>एपीआई: अनुरोध
alt सब ठीक है
एपीआई-->>क्लाइंट: 200 OKsequenceDiagram
क्लाइंट->>एपीआई: अनुरोध
alt सब ठीक है
एपीआई-->>क्लाइंट: 200 OK
endआपको क्या दिखता है
No diagram type detected matching given configuration
क्यों
कुंजी-शब्द में बड़े-छोटे अक्षर ग़लत हैं। `sequenceDiagram` चलता है; `sequencediagram` और `SequenceDiagram` नहीं। Mermaid अपने सभी कुंजी-शब्दों में बड़े-छोटे अक्षरों के प्रति संवेदनशील है।
समाधान
बड़ा D, बाक़ी छोटे अक्षर।
sequencediagram
क्लाइंट->>एपीआई: नमस्तेsequenceDiagram
क्लाइंट->>एपीआई: नमस्तेआपको क्या दिखता है
बन तो जाता है, पर संदेश बिना किसी पाठ के निकलता है
क्यों
कोलन के बाद कुछ नहीं है। मापा गया: Mermaid इसे ठुकराता नहीं — वह संदेश को ख़ाली लेबल के साथ बना देता है, और तीर बिना किसी व्याख्या के रह जाता है। जो सचमुच गिरता है वह कोलन को पूरी तरह छोड़ देना है: अकेला `क्लाइंट->>एपीआई` `Expecting 'TXT', got 'NEWLINE'` देता है। यानी कोलन अनिवार्य है और पाठ नहीं — जो सहज अनुमान के ठीक उलट है।
समाधान
कोलन के बाद कुछ लिखें, एक शब्द ही सही। बिना लेबल का तीर लगभग कभी वह नहीं होता जो आप चाहते थे।
sequenceDiagram
क्लाइंट->>एपीआई:
एपीआई-->>क्लाइंट: 200sequenceDiagram
क्लाइंट->>एपीआई: ऑर्डर बनाएँ
एपीआई-->>क्लाइंट: 200आपको क्या दिखता है
लंबी शर्त वाले `alt` के बाद Parse error
क्यों
खंड की शर्त के भीतर पंक्ति टूटी है। `alt`, `opt` या `loop` की शर्त एक ही पंक्ति में समानी चाहिए; तोड़ने पर उसका दूसरा आधा संदेश समझा जाता है और कहीं फ़िट नहीं होता।
समाधान
शर्त को एक पंक्ति में रखें। लंबी हो तो छोटा करें और ब्योरा टिप्पणी में ले जाएँ।
sequenceDiagram
alt ग्राहक के खाते में पर्याप्त
शेष राशि है
A-->>B: ठीक
endsequenceDiagram
alt ग्राहक के खाते में पर्याप्त शेष राशि है
A-->>B: ठीक
end
Note over A,B: शेष राशि दैनिक सीमा के विरुद्ध जाँची जाती हैआपको क्या दिखता है
बन तो जाता है, पर एक ऐसा भागीदार दिखता है जिसे आपने घोषित नहीं किया
क्यों
भागीदार के नाम में टाइपो है। Mermaid किसी नाम को पहली बार देखते ही भागीदार बना देता है, इसलिए `शिपिंग` और `शिपींग` दो अलग स्तंभ हैं और कोई चेतावनी नहीं आती। हिंदी में इसका सबसे आम स्रोत मात्राएँ हैं: इ और ई, उ और ऊ का एक बार का फ़र्क़ ही एक अतिरिक्त स्तंभ बना देता है।
समाधान
भागीदारों को शुरू में `participant` से घोषित करें। इससे टाइपो नहीं रुकेगा, पर यह दिख जाएगा कि सही नाम कौन-से हैं, और फ़ालतू स्तंभ तुरंत आँख में चढ़ेगा।
sequenceDiagram
ऑर्डर->>शिपिंग: पैकेट तैयार करें
शिपींग-->>ऑर्डर: पैकेट तैयारsequenceDiagram
participant ऑ as ऑर्डर
participant शि as शिपिंग
ऑ->>शि: पैकेट तैयार करें
शि-->>ऑ: पैकेट तैयारआपको क्या दिखता है
बन तो जाता है, पर स्तंभों का क्रम वह नहीं जो आप चाहते थे
क्यों
आपने भागीदार घोषित नहीं किए। घोषणा के बिना क्रम हर नाम के पहली बार आने से तय होता है, इसलिए आरेख के ऊपर जोड़ा गया एक संदेश सारे स्तंभ फिर से जमा सकता है और तीरों को एक-दूसरे के ऊपर से गुज़ार सकता है। आरेख सही बना रहता है, पर पढ़ने में काफ़ी बिगड़ जाता है।
समाधान
सारे भागीदार शीर्ष पर, उसी क्रम में घोषित करें जिसमें आप उन्हें देखना चाहते हैं।
sequenceDiagram
बैंक-->>नेट: डेबिट सफल
ग्राहक->>दुकान: ऑर्डर की पुष्टि
दुकान->>नेट: संग्रह अनुरोधsequenceDiagram
participant ग्राहक
participant दुकान
participant नेट
participant बैंक
ग्राहक->>दुकान: ऑर्डर की पुष्टि
दुकान->>नेट: संग्रह अनुरोध
नेट->>बैंक: आगे भेजें
बैंक-->>नेट: डेबिट सफलबनने के बारे में टिप्पणियाँ
Mermaid 11.12.2 पर मापा गया, वही संस्करण जो यह साइट चलाती है। सीक्वेंस आरेख दो ठोस बातों में बाक़ी सबसे अलग बरतता है।
हिंदी के लिए यह छहों में सबसे उदार प्रकार है
यह जानने लायक है क्योंकि यह राहत देता है। फ़्लोचार्ट और क्लास आरेख में देवनागरी पहचान के रूप में अस्वीकार होती है, पर सीक्वेंस आरेख में भागीदार की पहचान देवनागरी में पूरी तरह चलती है — जाँचा गया, `participant ग as ग्राहक` ठीक बनता है और सीधा `ग्राहक->>दुकान` भी। इससे भी अच्छा यह कि `as` के बाद वाला दिखने वाला नाम खुला पाठ है, इसलिए उसमें स्थान रखने की भी छूट है। यानी यहाँ हिंदी को कोई समझौता नहीं करना पड़ता।
चौड़ाई भागीदार तय करते हैं, संदेश नहीं
मापा गया: दो भागीदार 450 पिक्सल चौड़ा viewBox देते हैं, छह भागीदार 1250 — यानी हर अतिरिक्त स्तंभ पर लगभग 200 पिक्सल, चाहे संदेशों में कुछ भी लिखा हो। संदेश सिर्फ़ ऊँचाई जोड़ते हैं, हर एक लगभग 46 पिक्सल। एक अपवाद के साथ: अगर संदेश का लेबल स्तंभ की न्यूनतम चौड़ाई से चौड़ा है तो वह आरेख को सचमुच चौड़ा करता है। देवनागरी लेबल अंग्रेज़ी से सँकरे हैं, इसलिए यह अंग्रेज़ी की तुलना में देर से होता है।
इकलौता प्रकार जिसका viewBox ऋणात्मक से शुरू होता है
सीक्वेंस आरेख का viewBox `0 0` से नहीं बल्कि `-50 -10` से शुरू होता है। यह कोई ख़राबी नहीं: Mermaid वह हाशिया भागीदारों के डिब्बों के लिए छोड़ता है। यह सिर्फ़ तब मायने रखता है जब आप SVG को अपने औज़ारों से संसाधित करते हैं, क्योंकि शून्य से शुरुआत मान लेने वाली हर गणना पहला स्तंभ काट देगी।
यहाँ PNG निर्यात बिलकुल सही है
फ़्लोचार्ट तथा क्लास, स्टेट और ER आरेखों के विपरीत सीक्वेंस आरेख अपने लेबल सादे SVG पाठ के रूप में बनाता है, `<foreignObject>` के भीतर नहीं। इसी से वह सीधे रैस्टर हो जाता है: निर्यात किया गया PNG स्क्रीन से मेल खाता है, बीच में दोबारा बनाए बिना और टाइपसेटिंग खिसके बिना।
घोषित पर अप्रयुक्त भागीदार फिर भी बनता है
ऐसा `participant` जो न कोई संदेश भेजता है न पाता है, आरेख में एक ख़ाली स्तंभ के साथ दिखता है। कभी-कभी यह जानबूझकर होता है, किसी ऐसे पक्ष को दिखाने के लिए जो मौजूद है पर इस प्रवाह में शामिल नहीं। पर ज़्यादातर यह उस भागीदार का बचा हुआ निशान होता है जिसका आख़िरी संदेश हटा दिया गया और घोषणा हटाना भूल गए।
कब कोई दूसरा आरेख बेहतर है
अगर भागीदार सिर्फ़ एक है तो दिखाने को कोई क्रम है ही नहीं। एक स्तंभ और ख़ुद की ओर जाते तीरों वाला आरेख दरअसल असुविधाजनक ढंग से लिखा हुआ फ़्लोचार्ट है।
अगर आप कई पक्षों की बातचीत नहीं बल्कि वे अवस्थाएँ बताना चाहते हैं जिनसे कोई चीज़ गुज़रती है, तो स्टेट आरेख लें। संकेत साफ़ है: जब आप वही संदेश बार-बार अलग शर्तों के साथ लिख रहे हों, तो आपके सामने एक स्टेट मशीन है।
और अगर आदान-प्रदान पंद्रह संदेशों से आगे जाता है तो उसे बाँट दें। साठ संदेशों वाला सीक्वेंस आरेख तकनीकी रूप से सही और मनुष्य के लिए बेकार होता है; वह लगभग हमेशा तीन आरेखों के रूप में बेहतर पढ़ा जाता है, हर चरण के लिए एक, जिन्हें एक टिप्पणी जोड़ती हो।
अन्य आरेख प्रकार
लिखा Dominik Malsch · अंतिम अद्यतन: