To build a technical architecture presentation, show three things in order: where the system sits, how one important request moves through it, and why the proposed option is preferable to the alternatives. Finish with the decision you need. A component diagram alone cannot explain the behavior or the trade-off.
The example below follows a fictional retailer’s order service. Its team is considering a queue between order acceptance and fulfilment. The deck must help engineering and operations decide whether to pilot that change; it is not a design for a real production system.
Once the diagrams and comparison are ready, turn the architecture outline into editable slides with Presenti. Keep the technical reasoning in your input so the first draft has a useful story to arrange, rather than asking AI to invent a system.
Name the change the audience is being asked to accept
Write the decision before making a slide: “Approve a pilot of asynchronous fulfilment for accepted orders, while keeping payment authorization in the current path.” Add the boundary: payment-provider integration, database replacement, and the complete checkout redesign are outside this discussion.
This sentence determines which details belong in the deck. The operations lead needs to know what a delayed fulfilment job looks like. The engineering lead needs to know how retries and duplicates are handled. Neither needs a tour of every service in the company. If the expected user behavior is still disputed, settle it in a product requirements presentation before asking this review to choose an architecture.
Begin with the system’s neighbors
Use a context view with the customer, checkout application, order service, payment provider, and fulfilment service. Label relationships with their purpose, not just an arrow. “Authorizes payment” tells more than “API.” Mark the order service as the part being discussed and show external systems outside that boundary.
The C4 system-context guidance recommends this zoomed-out view of a system, its users, and connected systems before introducing low-level detail. You do not have to adopt every C4 diagram to use that separation of views.
Follow one order from acceptance to fulfilment
Use a numbered trace to explain what the proposed queue changes. The following is a sample flow for the fictional retailer. Sequence numbers should match the diagram so the presenter can point to a step without hunting for a box.
| Step | Interaction | What the audience should understand |
|---|---|---|
| 1 | Checkout sends an order request to the order service | The request has an order ID that can be used throughout the trace |
| 2 | Order service confirms payment authorization | A declined payment does not create a fulfilment job |
| 3 | Order service records the accepted order and a pending event | The design must address failure between recording the order and publishing the event |
| 4 | A publisher sends the pending event to the queue | Publishing may be retried; the event needs a stable identifier |
| 5 | Fulfilment receives the event and records its processing state | A repeated event must not create a second shipment |
| 6 | Operations sees the job status or a failed-job alert | The queue changes monitoring and recovery work as well as the request path |
A C4 dynamic diagram can show ordered runtime interactions for a specific use case. Use it selectively: the interesting part here is the failure and retry path, not every successful call.
Do not label this sample “exactly once” or “no lost orders.” Those claims require implementation details and tests that the presentation does not supply. Instead, point to the design questions: how pending events are recovered, how long failed jobs are retained, and who owns replay.
Compare the options on the same questions
A comparison slide should not put a paragraph of benefits beside a paragraph of disadvantages. Use identical criteria and make the cost of each option visible.
| Criterion | Direct call to fulfilment | Queue-backed fulfilment |
|---|---|---|
| Customer response | Acceptance depends on the fulfilment call’s behavior | Acceptance can be separated from later processing |
| Failure recovery | Retry behavior stays in the calling path | Requires job state, replay, and duplicate handling |
| Operational work | Fewer moving parts in this flow | Queue health, failed jobs, and processing lag need owners |
| Migration | No new message path | A pilot and rollback route are needed |
The table describes the design considerations, not measured performance. Add real latency or error data only when you can give the environment, period, sample, and source. Without that data, the honest recommendation is a bounded pilot—not an asserted improvement.
Package the argument into six slides
- Decision and scope: the proposed pilot and what it excludes.
- Context: the order service and its direct neighbors.
- Current pain: the observed incident, delay, or operational constraint that prompted the proposal.
- Proposed trace: the six interactions and the failure points.
- Options: the same four comparison criteria for both approaches.
- Pilot decision: owner, rollback route, tests, and the date for a go/no-go review.
For this example, the final slide could ask the platform team to test a publisher failure, a duplicate delivery, and a fulfilment outage before the pilot review. Each test needs an expected result and a person responsible for interpreting it. That gives the meeting a concrete output without pretending the deck itself settles the architecture. Once those tests are complete, use a release-readiness presentation to connect their results to the exact release candidate, remaining blockers, and the person authorized to make the go/no-go decision.
Create the six-slide draft in Presenti using your own trace, option table, and pilot conditions. Keep configuration, logs, and full test results in an appendix or linked design record, where reviewers can inspect them without overwhelming the main story.
