Sample architecture review report
This sample shows the shape of a Devsitia architecture review. It uses a generic system on purpose: no client names, no confidential details and no invented metrics. The point is to show what a buyer receives.
Executive summary
- The system is not failing because of one bad component. The main risk is that critical flows cross too many implicit boundaries: API, queue, worker, database and external provider all participate in the same business action, but no single trace or reconciliation process follows the action end to end.
- The next engineering cycle should not start with a rewrite. It should start by making the critical paths observable, idempotent and recoverable. Once those properties exist, the team can decide what deserves extraction or redesign with evidence instead of anxiety.
Example risk ranking
Payment retries are not idempotent end to end
High impact, medium effort. Introduce operation-level idempotency keys and reconciliation so provider timeouts do not create duplicate charges.
No trace connects API request, queue message and worker execution
High impact, medium effort. Add OpenTelemetry context propagation across async boundaries and standardise operation IDs.
Rollback exists procedurally, but not technically
High impact, medium effort. Split schema changes into expand/contract steps and rehearse rollback with real migration examples.
AI answers cannot be reconstructed
Medium impact, medium effort. Store source IDs, prompt version, model version and retrieval index version with each answer.
Cloud cost is not attributable
Medium impact, low effort. Add service and environment tags, then create monthly cost views by service.
Example findings
Finding 1: payment retries
The API accepts an idempotency key, but the key is not propagated to the worker that talks to the payment provider. A timeout after provider acceptance can create an unknown state or a duplicate operation.
Finding 2: async traces
Logs include request IDs at the API layer, but queue messages do not carry trace context. A single business operation cannot be followed without manual reconstruction.
Finding 3: rollback
The pipeline can redeploy a previous image, but migrations are forward-only. A rollback after schema change may restore old code against a newer schema.
Finding 4: AI outputs
The system stores final answers and feedback, but not retrieved source chunks, prompt version, model version or retrieval index version.
Example 30-day plan
- Week 1: introduce operation IDs across API, queue and worker; add structured logging to the critical path
- Week 2: add idempotency persistence, duplicate-message tests and trace propagation through async messages
- Week 3: add reconciliation for unknown payment states and record AI answer sources/model/prompt versions
- Week 4: rehearse rollback, review runbooks and convert findings into owned backlog items
How to read this sample
Is this a real client report?
No. It is a representative sample built from common findings. It intentionally avoids client names, confidential architecture and invented metrics.
Does every review find these issues?
No. The findings depend on the system. The format is the part being demonstrated: evidence, consequence, recommendation and a realistic plan.
Is the report a sales pitch for implementation?
No. A review is deliberately self-contained. The client can execute it with their team, another provider or Devsitia.
Why publish a sample?
Because buying a technical review is easier when the buyer can see what the deliverable looks like before the first call.
Start a conversation
Tell us what you are building, or what is currently breaking. You will get a straight answer from an engineer, not a sales script.