A feature can return the right result and still make the system harder to operate. The gap usually appears outside the demonstration: two requests arrive together, a dependency becomes slow, or someone needs to change a rule six months later. Good engineering makes those situations understandable before they become emergencies.
Correctness still comes first. The useful next question is: under which conditions does this result remain correct, and what evidence supports that claim? That question connects implementation to the people who will run, maintain, and depend on it.
A successful request is only one observation
Consider an illustrative invoice endpoint. It validates the order, saves an invoice, calls an email provider, and returns success. A manual test creates one invoice and receives one email. The feature appears finished.
Now let the email provider accept the message but time out before replying. If the client repeats the entire request, does it create another invoice? If the endpoint instead reports failure after saving the invoice, what should the user believe? The code needs a model of the business operation, not just a sequence of calls.
Write the invariant first: one logical request must create at most one invoice, and delivery status must remain recoverable. An idempotency key and a durable delivery record are possible parts of the design. They have to be connected to the same operation and enforced under concurrent requests. Merely checking whether a record already exists is not enough if two callers can pass that check together.
Make ownership and failure visible
A useful design names the owner of each state transition. The invoice may be committed in the local database while notification remains pending. A worker can attempt delivery and record its outcome. If a separate queue is involved, the design must account for a crash between committing the invoice and sending the message; a transactional outbox is one approach to that gap.
This does not mean every endpoint needs a queue. It means that the choice to add one, or to keep work synchronous, must follow the required failure behavior. If notification is optional and can be retried by an operator, a smaller solution may be sufficient. If it triggers a business obligation, a missing delivery record can be a correctness problem.
Review how the next change will work
Imagine that invoices now need a different tax rule for one customer group. A maintainable implementation lets the engineer find that rule, understand its inputs, change it, and verify the affected behavior. It should not require reconstructing the email provider, HTTP framework, and storage adapter to reason about the calculation.
Keep domain rules separate from transport and delivery details where that separation gives a concrete benefit. A small function with explicit inputs may be more useful than an elaborate hierarchy of interfaces. A boundary earns its place when it contains a reason to change or makes an important rule easier to test.
Include operation in the definition of done
A system that fails silently asks its users to discover its problems. For the invoice example, useful signals might include pending-delivery age, repeated failures, duplicate-request recognition, and a correlation identifier that connects the request to its delivery attempt. Logging the entire invoice or a secret provider token is neither necessary nor appropriate.
The release also needs a recovery path. Can an operator find a stuck operation and retry it safely? Can a schema change be deployed while older application instances still run? Can the team reverse a bad release without discarding records that users have already created?
A small review that changes the conversation
Before approving a feature, ask for a short explanation of its important decisions. Four prompts are usually more useful than a demand for a larger diagram:
- Which business rule must always hold, including during concurrent requests?
- What happens when a dependency succeeds but the response is lost?
- Where would a maintainer change the most likely next requirement?
- How would an operator recognize and recover a partially completed operation?
The answers do not need to describe a perfect system. They need to make the remaining uncertainty explicit. A known limitation can be accepted with context; an invisible assumption cannot be managed.
Try the reasoning on a model
Use the Architecture Trade-off Simulator to compare synchronous and background work. Observe how moving work changes request latency while leaving worker capacity as a separate constraint. The model is educational, so it does not prove that an invoice design is safe; it helps separate two questions that a fast response can otherwise blur.
Working code answers whether an implementation can perform an operation. Good engineering also explains the conditions under which that operation remains trustworthy and the practical steps available when those conditions fail.