Editorial illustration.
Originally published 16 June 2023; rewritten and reviewed on 15 October 2026.
A browser screen sends a request, the server writes a record and a background process sends a notification. To the user, it is one action. To the application, it crosses several boundaries with different failure modes. I would draw those boundaries before choosing an elaborate architecture diagram.
Follow one user action through the system
Identify what the browser submits, how the server authenticates the caller and where business rules are enforced. Trace the write into storage, then identify any work that continues afterwards.
Keep the authoritative rule on the trusted side of the boundary. A browser can make the form convenient, but it cannot establish that a user is permitted to change a particular record.
Separate responsibilities without inventing layers
Presentation, application logic and persistence often deserve distinct responsibilities. That does not require a separate network service for each one. A small, well-structured application may be easier to operate than several services with unclear ownership.
A background task becomes appropriate when work outlives a request or needs controlled retries. It then requires durable state, an owner and a way to distinguish queued, completed and failed work. Moving code into the background does not remove its operational obligations.
Design the failure path alongside the happy path
Ask what happens when a database is unavailable, a message is repeated or an external service times out. Decide which operations can be retried and how duplicate effects are prevented. Carry a diagnostic identifier across components where appropriate, without leaking secrets into logs.
Review deployment, backups and recovery as part of the design. An architecture is useful when the team can explain how a user action completes, how an incomplete action is discovered and who can restore the service. The diagram should make that explanation easier, not replace it.