Does FBP require a graphical editor?

No. Network connections can be represented textually; a visual representation is useful but not the defining requirement.

Must every process run on a separate machine?

No. Processes may run within one runtime or another supported arrangement. Distribution is an implementation choice.

Is FBP the same as functional programming?

No. They address different concerns, although components or specifications can use functional techniques.

AI Glossary / Data engineering and architecture / Intermediate

Flow-based programming

Definition

Flow-based programming is a programming approach that defines an application as a network of asynchronous processes exchanging structured information packets through connections. In its classical form, named ports, bounded buffers and an externally defined network separate component behavior from the arrangement of the application.

What it means

Each component performs a particular kind of work on incoming information and sends results through its output ports. The network definition determines which ports connect to which other processes. A reusable component can therefore participate in different applications without embedding the whole application's wiring in its code.

The approach is associated with J. Paul Morrison and is a particular form of dataflow programming. A diagram containing boxes and arrows is not automatically a flow-based program.

Flow-based programming also differs from merely listing sequential workflow steps. Several processes can be active independently as data becomes available and output capacity permits. The resulting behavior depends on the network, the components and the execution system.

How it works

A component defines its ports and processing. A network creates process instances and connects their ports. More than one process instance can use the same component code while maintaining separate working state.

Information packets move through the connections. Classical FBP gives packets defined ownership and lifetimes: a packet belongs to a process or is in transit, rather than being an unrestricted shared object. This helps structure communication, although component code still needs to respect the implementation's rules.

Connections have finite capacity. If an ordinary blocking connection is full, its producer cannot simply continue adding packets without limit. If no input is available, a consumer may wait. These rules provide coordination and pressure between stages; particular implementations may also offer explicitly different connection policies.

The runtime schedules processes according to its execution model. Concurrency does not guarantee physical parallelism, and a network can still deadlock if its waiting relationships are poorly designed. Error paths, stream completion, state and external side effects must therefore be specified as carefully as the normal data path.

Three practical examples

A document-processing network separates reading, validation, extraction and output formatting into reusable components.
A monitoring application filters incoming observations, groups relevant events and produces summaries through connected processing stages.
A teaching system swaps a simulated input component for a real source while retaining compatible ports and downstream processing.

Think of it this way

Think of a production line whose workstations receive items, transform them and pass them onward through limited holding areas. The arrangement of stations is separate from the instructions for each station.

The analogy is limited because software packets, ownership and scheduling follow precise rules. A diagram does not guarantee sufficient capacity, freedom from deadlock or correct handling of failures.

Worked example

Understanding a bounded connection

An invented two-stage network has a producer capable of creating one hundred packets per second and a consumer capable of handling sixty per second. Their connection can hold two hundred packets and starts empty.

Ignoring short-term scheduling effects, the queue grows by 100 − 60 = 40 packets per second while both rates remain steady. It reaches its capacity after 200 ÷ 40 = 5 seconds.

With the assumed blocking behavior, the producer must then wait when there is no room. Over a sustained period, the consumer's sixty-packet rate limits throughput through this connection. Increasing the buffer would absorb a longer burst but would not raise that processing rate.

The calculation assumes uniform packets and constant rates. Real systems have variable processing times and other bottlenecks. If a connection instead uses an explicit dropping policy, the consequences differ and must be part of the application contract.

Illustrative case study

A fictional training-content company builds a pipeline that reads course files, validates their structure, extracts text and sends selected content for AI-assisted categorization. It gives each component a clear packet format and separates the network wiring from the component implementations.

Testing shows that the categorization stage is slower than file reading. Bounded connections prevent unlimited accumulation, while monitoring identifies where work waits. The team routes invalid files to a defined review path instead of allowing them to stop an unrelated stream silently.

It also handles external requests with stable identifiers and an explicit retry policy. The FBP network organizes communication, but it does not automatically make a remote model request repeatable without cost or changed output. The case illustrates modular coordination alongside responsibilities that still belong to the application.

Common misconceptions and mistakes

Every visual workflow tool implements FBP. The execution, packet and connection semantics must be examined.
More buffers increase sustained throughput indefinitely. A slow stage remains a capacity limit.
Asynchronous processes cannot deadlock. Waiting cycles and poorly coordinated streams can still prevent progress.
Reusable components need no shared agreements. Their ports, packet structures and completion behavior must be compatible.

Business use

Flow-based programming can make transformation pipelines easier to assemble and discuss when component contracts are clear. It can also support reuse across applications whose wiring differs but whose processing steps are similar.

Evaluate the runtime and component library against actual requirements: state handling, error propagation, debugging, deployment and external integrations. A convenient network editor does not by itself establish these capabilities.

For AI workflows, distinguish the flow structure from the reliability of each model or tool call. Record which component owns validation, how uncertain results are represented and whether failed requests can be retried safely. Measure useful completion and waiting time across the network instead of counting how many processes run concurrently.

Check your understanding

A producer supplies one hundred packets per second and a consumer handles sixty. Will doubling a bounded buffer necessarily double sustained throughput?

Answer: No. It can delay when the buffer fills, but the consumer's processing rate remains the limiting rate under the stated assumptions.

Related terms

Dataflow programming
information packet
bounded buffer
backpressure
component
port
concurrency
deadlock

Learn next

Read bounded buffer and backpressure. Draw a three-component network and define each packet format, completion signal and error route. Then identify what happens when the middle component becomes slower than its producer.

Sources

J. Paul Morrison, Flow-based Programming, Introduction: https://www.jpaulmorrison.com/fbp/introduction.html. Primary explanation of networks, processes and externally defined connections.

J. Paul Morrison, Flow-based Programming, Concepts: https://www.jpaulmorrison.com/fbp/concepts.html. Primary description of ports, bounded buffers and information-packet ownership. Performance claims are not generalised across implementations. The queue calculation and training-content case are original illustrations.

Previous: Flow-based Minimum Cuts Next: Flow matching