Supplier-buyer model

Design your system by components, and provide means for them to intercommunicate. On any system, components communication looks as next (parallelism was left out for simplicity purposes):

This resembles a manufacturing line, where products get built as they move from step to step:

On a manufacturing line, all stations (steps) work under the Supplier-Buyer model:

1. Each station acts as if it was a buyer from the previous station (supplier): When receiving the product from the previous station, it can decide whether to buy it or reject it.
   1. Each buyer has a measurable quality acceptance-criterion that is verified before buying the product.
   2. If the supplier provides items below the expected quality, then the buyer simply rejects it (in the case of the very first station, the supplier is usually the stockroom).
2. Once a station buys the product, it will perform the next set of actions over the product.
   1. Once it has completely finished doing its part of the process, the buyer becomes a supplier and sells the product to the next station.
3. By the end of the manufacturing line, the last station sells a finished good to the supply-chain, the stockroom, another manufacturing line, etc.
   1. This process continues being applied during the rest of the supply-chain process until it reaches the end-consumer.

Each station demands high quality when buying items from the previous supplier, and it also concerns on not supplying defective items to the next buyer..

In a similar fashion, each system’s component can be designed as next:

This follows the supplier-buyer model: If the supplier provides low-quality items (exits with a poor post-condition state), the buyer can simply reject it (i.e., pre-condition state was not met).

Under this model, changing components usually isolate all risks into a single area, and replacing components code becomes easier: all we care about is that all incoming work meets the pre-condition criteria, and that the post-condition is properly constructed for further steps.

This model can be applied both for synchronous and asynchronous operations, thus making it easy to adopt regardless of the system’s components workflow.

When combined with processing-queues this model shines, as it allows async scaling, sending items back to previous steps, retry operations, etc.

This model also adopts the fail-fast best practice, and makes refactoring less risky as all components work under promises both ways.