Database and Data Flow Diagram

What this diagram shows

This diagram maps the movement of data through an order processing system, connecting databases, application processes, and external services. It shows which systems hold which data (orders, customers, inventory, payments), which processes transform or validate that data, and the flows between them. For example, an order entry process reads from a customer database, writes to an orders table, triggers inventory updates, and sends data to a payment gateway. The diagram makes visible where data originates, where it lives, how it moves, and what happens to it at each stage.

Key components

• Data Store — A persistent repository such as a relational database table, cache, or file system that holds orders, customer records, product inventory, or transaction logs.
• Process — A defined operation that reads input data, applies business logic (validation, calculation, transformation), and produces output data.
• External System — A third-party service or API outside your control, such as a payment processor, email service, or shipping provider that receives or sends data.
• Data Flow — A labelled arrow showing the direction and type of data moving between a process and a store, or between two processes.
• Actor or User — An external person or system that initiates a transaction, such as a customer placing an order or an admin running a report.
• Transformation Step — A process that converts raw input (unvalidated order details) into a different state (confirmed order with calculated totals and assigned ID).
• Feedback Loop — A data flow that returns information from a downstream process back to an earlier stage, such as payment confirmation flowing back to order status.

When to use it

Use this diagram when designing or documenting a system where data consistency and movement are critical: e-commerce platforms, booking systems, invoice processing pipelines, or financial transaction workflows. It is most valuable during system design, when integrating new services, or when debugging data inconsistencies. It helps teams agree on data ownership, identify missing validation steps, and spot where systems are tightly coupled or single points of failure exist.

Common mistakes

• Showing data flows without labels, making it impossible to know whether a flow carries customer IDs, full records, or transaction status.
• Mixing logical processes (what should happen) with technical implementation (which service does it), creating diagrams that neither architects nor developers can act on.
• Omitting error paths and exception handling, so the diagram suggests data always flows smoothly when in reality rollbacks, retries, and failed payment handling are critical.

Adapting it to your system

Start by listing your data stores (database tables, files, APIs you consume). Then identify your core processes (order entry, payment, fulfillment, reporting). Draw flows between them and label each with the data that moves. Mark external services clearly. Add a legend showing process types (synchronous, asynchronous, batch). Colour-code by system owner or criticality. Walk through a real transaction (a customer order from start to invoice) and verify every step appears. Remove any process that does not read or write data.