DataFlowPatterns
How work/data actually branches, merges, and moves through a processing chain — distinct from ArchitecturePatterns (overall system shape) and CommunicationPatterns (transport/interaction style).
Why we need this / what value this brings
Naming the actual shape of a data flow (fan-out, pipeline, scatter-gather) makes it easier to reason about failure modes and parallelism than describing it ad hoc.
When to use this
When designing any workflow that involves more than one processing step or more than one consumer of the same trigger.
How to use or implement this
Sketch the flow as boxes and arrows first, identify which named pattern(s) it matches, then apply that pattern's known failure-handling concerns (e.g. fan-out needs per-branch failure isolation).
Subtopics
Research questions
- Which of these already shows up implicitly in Localz today — e.g. a booking event fanning out to email + SMS + analytics — without being named as a pattern?
Empty folder — drop notes, links, and findings here as you research.