Orders API sends a confirmation email by calling Email Service during checkout. The team decides that a slow email provider should no longer hold up the order response. Someone adds a queue between the two boxes on the architecture diagram. Has the design changed, or has the drawing merely gained a box?
The answer depends on whether the old connection had a meaning the editor and the next reader can recover. The new path is asynchronous: Orders API submits a confirmation job to a queue, and Email Service consumes it later. The old path made checkout wait for Email Service's reply; the new path can return before the send even starts. Neither path, as drawn, proves delivery to an inbox. The design has changed even if most boxes stay in the same place.
A local edit has a larger meaning
Start with a small fictional request-flow view. The client calls the Orders API. Orders API writes the order to Orders DB, then calls Email Service to send a confirmation; Email Service calls the email provider. Draw the two outgoing relationships from Orders API separately. One is a database write. The other is a synchronous request that can delay the API response. The labels tell a reviewer why replacing one arrow should leave the other alone.
After the decision, Orders API and Orders DB keep their identities and their relationship. Email Service also keeps its identity and provider connection. The synchronous Orders API to Email Service relationship is removed. Orders API now publishes a confirmation job to a queue; Email Service consumes that job. The two new, directed edges should say "publishes confirmation" and "consumes confirmation". Neither edge means "email delivered." If the editor merely bends the old arrow through a new rectangle, the picture may imply that the API still waits for the email. The diagram must represent a changed relationship, not only a changed route across the canvas.
This revision has a real cost. The client may see a completed order while its confirmation is pending. The team must decide what the API returns if the order is saved but publishing the job fails. Retries also raise duplicate-email questions, and the team may need a status or support path for confirmations that never send. The diagram cannot decide these policies, but it can make the changed timing and the missing path visible to the people deciding them.
What the source must remember
An exported PNG is useful in a review document because everyone sees the same snapshot. Its pixels do not identify which rectangle is Orders API or which line is the synchronous email call. Editing that image later means reconstructing those objects or painting over them. A file of separate shapes gives you more control: you can move a box, change a label, and reconnect a line. Yet a line snapped to two shapes still may not say whether it is a request, a published job, or a deployment dependency.
For the order change, the editable source needs stable identities for Orders API, Orders DB, and Email Service, plus distinct identities for their relationships. The old email call must be removable without touching the database write; the publish and consume relationships must be new, separately addressable connections with their own direction and meaning. Then a local edit can replace the email relationship and preserve the database relationship. Moving Orders API on the page should not turn it into a new service. Renaming Email Service should not silently create a second component or sever its provider connection.
This does not require an editor to understand every operational consequence of a queue. It requires the source to keep the author's distinctions available for the next revision. The Software Engineering Institute's Views and Beyond guidance discusses architectural views, interfaces, behavior, and design rationale as parts of architecture documentation. A diagram is one view of the system; labels and accompanying decisions remain part of the work. SEI book record.
Choose the master for the next change
An image may be the right output for a slide or a signed-off design snapshot. A flexible shapes file may be enough when the team is sketching freely and the author can explain every line. If the diagram will carry precise revisions across reviews, keep a source in which the components and connections can be addressed individually. Export images from that source when people need a snapshot.
The next review of this order system might move email composition into the worker or add a failure route. With an editable model, the team can name the existing Email Service and the specific queue-consumer relationship, make that change, and inspect what stayed intact. If the tool cannot preserve those identities, someone must reconstruct the intent from the picture each time. That reconstruction is where a small design change becomes an argument about what the old diagram meant.
Lycana gives you a canvas of editable diagram elements alongside spoken and typed instructions. Try the order change there: name the old Email Service connection, replace it with the queue path, and inspect whether the Orders DB relationship still says what you intended. The result is a diagram to review, not evidence that the delivery design is sound.
