Tutorial4/4

4. Run the fan-out

In this chapter you run the three-Component System and watch one message become two deliveries.

Reseed and run

The first run swept the source file, so seed it again. From the workspace root, using the Taskfile from chapter 2:

task seed
task run

The Aspire dashboard now shows three Component processes instead of two, each with its own Dapr sidecar. The extractor sweeps the file and publishes it once.

Check it

Both destination folders receive the order:

cat order-notifications/test/wms-loader-destination/ORD-1001.json
cat order-notifications/test/web-loader-destination/ORD-1001.json

{"OrderId":"ORD-1001","CustomerId":"CUST-42","LoadedAt":"2026-08-17T07:53:07.179879+00:00","Status":"Loaded"}
{"OrderId":"ORD-1001","CustomerId":"CUST-42","LoadedAt":"2026-08-17T07:53:07.493233+00:00","Status":"Loaded"}

One publish, two deliveries: the broker gives each subscribing Component its own copy, and each loader ran its own pipeline, wrote through its own Port, and recorded its own trace. The LoadedAt timestamps differ because the two deliveries are independent — neither loader knows the other exists, and nothing in either scaffold changed between chapter 2 and now.

That independence is the property the Distribution shape buys. A third destination is another loader and another AddLoader block; a loader that is down does not stop the others; and each loader classifies and routes its own business incidents to its own owner.

Stop the host with Ctrl+C. The System is done.

Where to go from here

You composed a System without writing pipeline code. To see what the sample logic inside each Component actually does, and to write those steps yourself, take the transactional integration tutorial. To take a System like this one toward real environments — immutable releases, staging, promotion — start at Build, connect, deploy and continue on the intropy.run tab.