Transaction flow in Brindell Ledger, a fictional bookkeeping app
Architecture flow slide a non technical board can follow
An architecture flow slide shows how a request or a record travels through the parts of a system, in order, with a short note on what each part does. This one explains to the board of Brindell Ledger, a fictional bookkeeping app, how a sale recorded in the app becomes a balanced ledger entry.
What is on the slide
- Title and framing line
- Transaction Architecture Flow. Brindell Ledger, from a sale in the app to a balanced ledger, in plain terms.
- Flow rail
- 01 Mobile and Web App, 02 API, 03 Job Queue, 04 Matching Worker, 05 Ledger Database.
- App and API cards
- App: the bookkeeper snaps a receipt or records a sale, sent the moment there is signal. API: checks who is signed in and that the business is theirs, accepts the record in under a second.
- Queue and database cards
- Queue: holds each record in line so a busy month end slows matching instead of dropping work. Database: every matched entry with a dated history, copied to a second region every night.
When this is the right slide
Pick this slide when a board, buyer or new team needs to see how a record moves through a system in order, with plain English notes on the layers where cost and risk sit.
What to swap it for
Code: API Contract (Request / Response / Notes). Use the API contract layout for developers who need the method, endpoint, request and response of one call rather than a plain tour of the layers.
What this slide shows
The title reads Transaction Architecture Flow, with the framing line Brindell Ledger, from a sale in the app to a balanced ledger, in plain terms. On the left, a vertical rail joins five numbered discs: 01 Mobile and Web App, 02 API, 03 Job Queue, 04 Matching Worker and 05 Ledger Database. On the right, four light cards carry a heading and one sentence each. App, where the bookkeeper works: the bookkeeper snaps a receipt or records a sale, and the app sends it the moment there is signal. API, the front door: checks who is signed in and that the business is theirs, then accepts the record in under a second. Queue, nothing gets lost: holds each record in line, so a busy end of month slows matching instead of dropping work. Database, one source of truth: stores every matched entry with a dated history and is copied to a second region every night. The cards do not line up one to one with the rail, so the presenter points across as the story moves down.
When this is the right slide
Use an architecture flow slide when a mixed or non technical audience needs a shared picture of how a system works: a board meeting, an investor due diligence session, a sales call with a buyer's finance team, an onboarding session for new staff outside engineering. It answers what the parts are and what happens to the customer's data. It is the wrong slide for engineers who will build against the system, who need endpoints, payloads and errors, and the wrong slide for systems that branch, which need a flowchart. Keep the card language at the level of the audience in the room, not the level of the team that built it. The slide is equally useful in a sales meeting with a buyer's finance or risk team, who often need to sign off a supplier but do not read technical documents. Showing the five layers with plain notes on access and backups gives them what they need for that sign off, and it shows that the supplier can explain its own system clearly to people outside engineering.
How to adapt it
First, swap the four cards for four risks when the slide goes to an audit or risk committee, for example data loss, unauthorised access, outage at month end and supplier failure, each tied to the layer that handles it. Second, add one number per card for an investor audience, such as records processed per day at the queue. Third, follow the slide with an API contract slide for a developer audience, keeping the same five layer names so the two slides read as one story. Keep the rail labels short enough to fit on one line, and avoid product names of cloud services unless the decision in the room is about them.
What makes this slide work
Every card heading is a plain promise
App: where the bookkeeper works. API: the front door. Queue: nothing gets lost. Database: one source of truth. Each heading names the layer and then says what it means for the business, so a director can read the four headings alone and understand the system.
The rail shows the order of the journey
Five numbered discs on a vertical rail run from Mobile and Web App to Ledger Database. The numbers and the line make the direction obvious, and the presenter can trace a single record down the rail while talking.
Risk answers are built into the cards
The queue card says a busy end of month slows matching rather than dropping work, and the database card says data is copied to a second region every night. Those are the two questions boards ask about any system, and the slide answers both without a separate risk slide.
Questions people ask
How technical should an architecture slide for a board be?
Technical enough to name the real parts, plain enough that a director can repeat it. Name each layer, such as API or job queue, then say what it does in everyday words: the front door, nothing gets lost. Leave out frameworks, cloud services and version numbers unless the board is deciding on them.
Why does the flow have five steps but only four cards?
The layout pairs a five step rail with four detail cards, so one layer goes without a card. Here the matching worker is left out because it is the least surprising to a board: it does the matching. The four cards cover the layers where risk or cost sits, which is what directors ask about.
Should an architecture flow slide show security?
For a board, yes, in one line where it happens. The API card here says it checks who is signed in and that the business is theirs, and the database card says it is copied to a second region every night. Those two lines answer the questions most directors bring about access and data loss.
When is a diagram better than a flow rail?
When the system branches, loops or talks to several outside services at once. A straight rail assumes one path from top to bottom. If records can go to two places, or a third party service is involved, use a flowchart that can show the branches and the outside parties.
Can the same architecture slide go to engineers?
It can open an engineering talk as a shared picture, but engineers will want more on the next slides: the request and response format, error handling and load figures. Keep this plain version for mixed audiences and follow it with a detailed contract slide when the audience builds or integrates with the system.
How do I present an architecture flow slide to non technical people?
Tell the journey of one real record, such as a receipt for $86 snapped on a phone, from the top of the rail to the bottom. Point to each card as the receipt reaches that layer. A single story makes the parts memorable without anyone needing to understand how they are built.
Build your own in about a minute
The button below opens the generator with this use case already described. Change the wording to match your own, generate, then edit anything you like.
Make one like thisOther slide examples
Sprint cycle slide with the length of every ceremony
A sprint cycle slide shows the loop a team repeats every sprint, planning, building, reviewing and reflecting, and how long each part takes. This one shows how the team behind Tillsby, a fictional farm records app, runs a ten working day sprint that ends with a working increment every time.
Kanban slide showing a sprint board on a single date
A kanban slide shows where every piece of work sits right now, sorted into lanes such as To Do, Doing and Done, so a room can see progress without reading a ticket list. This one freezes the Sprint 14 board of Rostrel, a fictional shift planning app, on day 8 of 10.
Onboarding process slide with an owner on every step
An onboarding process slide shows the steps a new employee goes through from accepting an offer to being settled in the role, and who is responsible for each. This one maps eight steps at Haverleigh Care, a fictional care provider, from a signed offer to the 90 day review.
Want the steps in the builder? Read Add charts, maps and diagrams to slides, then Add, reorder and restructure slides. For everything this generator can do, see the slide maker.
Written and checked by the OneCraft team. Last checked .