T03: Links and Direction

2.3.1 Why Links and Direction Matter

In a flowchart:

• Nodes define meaning

• Links define movement

• Direction defines layout

If nodes represent structure, links represent behavior.

A poorly structured linking strategy leads to:

• Crossing lines

• Ambiguous flows

• Hard-to-read diagrams

Mastering links and direction ensures your diagrams are both logical and readable.

---

2.3.2 Declaring Direction

Every flowchart begins with a direction declaration:

Direction options:

Code	Layout
TD	Top → Down
BT	Bottom → Top
LR	Left → Right
RL	Right → Left

---

Example 1 — Top to Down

---

Example 2 — Left to Right

Direction changes layout — not logic.

---

2.3.3 Basic Link Syntax

The most common link:

A --> B

This means: Node A flows into Node B.

Example:

---

2.3.4 Different Link Types

Mermaid supports multiple edge types.

1. Standard Arrow

A --> B

---

2. Reverse Arrow

A <-- B

---

3. Undirected Link

A --- B

Used when relationship is non-directional.

---

4. Thick Link

A ==> B

Indicates strong or emphasized flow.

---

5. Dotted Link

A -.-> B

Often used for:

• Optional flows

• Asynchronous communication

• Conditional paths

---

2.3.5 Labeled Links

You can label connections:

A -->|Yes| B

Example:

Labeled links are essential for decision modeling.

---

2.3.6 Multiple Links from One Node

A node can branch into multiple paths:

This represents fan-out architecture.

---

2.3.7 Merging Links

Multiple nodes can converge into one:

Used for:

• Aggregation

• Merge operations

• Workflow convergence

---

2.3.8 Chained Links

You can simplify:

Equivalent to writing each link separately.

Use chaining for linear flows only.

Avoid chaining when branching exists.

---

2.3.9 Controlling Flow Clarity

Direction affects readability.

Compare:

Vertical Layout

Horizontal Layout

Horizontal layout is often better for system architecture.

Vertical layout works well for:

• Algorithms

• Sequential processes

• Step-by-step workflows

Choose direction intentionally.

---

2.3.10 Looping Links

Loops represent repeated execution.

Loop direction impacts readability.

Place decision above process when using TD layout.

---

2.3.11 Complex Example — Full Workflow

Let’s build a realistic checkout flow.

Observe:

• Clear direction

• Labeled branches

• Loopback logic

• Structured layout

---

2.3.12 Link Styling (Basic Preview)

You can style links:

linkStyle 0 refers to the first link.

Styling will be covered in detail later, but understanding that links are index-based is important.

---

2.3.13 Common Mistakes

1. Using -> instead of -->

2. Mixing directions unintentionally

3. Overcrowding diagram with crossing links

4. Failing to label decision branches

5. Using dotted links inconsistently

Incorrect:

A -> B

Correct:

A --> B

---

2.3.14 Design Guidelines

For professional diagrams:

• Choose direction based on diagram purpose

• Avoid unnecessary cross-links

• Use dotted links for optional flow

• Use thick links sparingly

• Always label decision branches

• Keep linear flows chained for clarity

Think structurally, not visually.

---

2.3.15 Hands-On Exercise

Build a Microservice Request Flow:

Requirements:

• User sends request

• Gateway routes request

• Gateway sends to Service A or Service B

• Service B optionally calls External API (dotted link)

• All responses return to Gateway

• Gateway responds to User

Constraints:

• Use LR direction

• Include at least one dotted link

• Include at least one labeled link

• Ensure no unnecessary crossing lines

---

2.3.16 Key Takeaways

Links define how information moves through a system.

Direction defines how that movement is visually structured.

Understanding:

• Arrow types

• Labeling

• Loop construction

• Branching patterns

• Layout orientation

is critical for building readable and scalable flowcharts.

In the next chapter, we move beyond flowcharts and begin exploring Sequence Diagrams, where time and interaction order become central concepts.