This article is based on my book — Designing Trading Systems: Trade Booking, Lifecycle, and Flow - a hands-on guide for folks in financial engineering industry.

TL;DR:

Good system design isn’t about what functions a component performs, but how information flows through it. Whether one-to-one, fan-in, or fan-out, flows define how systems interact, synchronize, and evolve together. Thinking in flows turns static designs into dynamic, living systems.

Context

In any complex environment, systems rarely exist in isolation. Each one is connected to others, forming a larger system — which in turn becomes a component of something even bigger. This nesting is recursive across every scale we observe.

In nature, light is a flow connecting the Sun and the Earth, transferring energy and enabling life. In human society, flows of trade, migration, information, and finance connect countries and economies into a global network. The same pattern appears in technology: data flows connect applications, control flows connect processes, and event flows connect services.

The behavior of any system is ultimately shaped by its flows — what comes in, what transforms inside, and what goes out. That’s why a good system designer doesn’t think in static functions but in dynamic flows — of data, control, energy, or information.

Understanding and modeling these flows is what separates a code-level thinker from a system-level designer.

Types of Flows

Broadly speaking, system flows can be categorized into three archetypes:

1. One-to-One Flows
2. Fan-In (Many-to-One) Flows
3. Fan-Out (One-to-Many) Flows

These patterns are universal — they apply equally to software, trading systems, logistics networks, or even biological ecosystems.

One-to-one Flow

The simplest kind of flow connects one source to one destination.

Take a command-line console as an example: A user inputs data → the program processes it → and outputs a result. This direct interaction defines a clear boundary and predictable behavior. The quality of design lies in how cleanly input is transformed into output — through validation, transformation, and feedback.

In more complex systems, one-to-one flows chain together into sequences. Consider a trading system: when a trade is booked, it passes through multiple lifecycle events — enrichment, validation, confirmation, and settlement. Each stage is effectively a one-to-one transformation on the same trade, evolving its state from raw booking to confirmed transaction.

The clarity of these flows ensures that each stage is deterministic and traceable — vital for system stability and auditability.

Fan-In (Many-to-One) Flows

In a fan-in flow, multiple inputs converge to trigger or influence a single process.

For example, a pricing engine in a trading platform consumes multiple data feeds — market quotes, yield curves, FX rates, and instrument definitions. The system must synchronize these flows in both timing and consistency to produce a coherent price. If one source lags or misaligns, the result becomes unreliable — illustrating that flow coordination is as critical as flow logic.

Fan-in flows demand strong mechanisms for:

• Aggregation: combining streams intelligently.
• Prioritization: deciding which flow takes precedence.
• Synchronization: handling latency and version mismatches.

In essence, fan-in is about alignment under concurrency — a hallmark of mature system design.

Do you find this valuable? Subscribe here! for more 😃 or check out my book — Designing Trading Systems Volume 1 for deeper insights into real-world system design

Fan-Out (One-to-Many) Flows

In a fan-out flow, a single system disseminates its output to multiple downstream systems or components.

For instance, after a trade is booked, the trade booking system might distribute the trade event to:

• Risk and P&L engines
• Position management systems
• Regulatory reporting platforms
• Data warehouses

Each downstream consumer applies the data differently — one for risk aggregation, another for compliance, another for analytics. This is where consistency, contract design, and versioning become crucial. A small schema change in the source can ripple through all dependents if the flow contract is not properly managed.

Fan-out patterns highlight the importance of publish–subscribe architectures, event schemas, and data lineage — ensuring that information flows outward without losing integrity.

Closing Thoughts

Thinking in flows means understanding not just what a system does, but how information moves, transforms, and propagates through it.

Functions describe actions, but flows describe relationships — and it’s relationships that define system behavior.

When you begin to see your systems as networks of flows — one-to-one, fan-in, fan-out — you start designing for resilience, traceability, and evolution, not just correctness.

That’s the shift from coding systems to designing systems that think.

Enjoyed this post? Check out my book — Designing Trading Systems: Trade Booking, Lifecycle, and Flow for deeper insights into real-world system design.