Back to daily archive
Architecture/

Adoption is architecture: Synchronous or asynchronous

JSBC Labs retrospective note4 min read

Why this deserves attention

Timing is an architectural decision: a process should wait only when the immediate response genuinely changes the next action. The important work is to turn the assumption into a visible decision.

Unnecessary synchronous dependencies increase latency, couple availability and make user journeys fragile. On 27 December 2025, this archive entry records the principle as a practical design concern rather than a product announcement.

Design the human system

Look at synchronous or asynchronous through how the user experience and operating model determine whether the capability is used. The objective is not to introduce more process; it is to expose the few decisions that determine reliability, ownership and future change.

Classify the business need first, then choose request-reply, event-driven or scheduled movement based on urgency and recovery needs. Record the decision close to the solution so that delivery, support and future architecture reviews work from the same intent.

What good looks like

The resulting design meets the real service expectation without forcing every system to be available at the same moment. The team can describe the expected behaviour, the owner, the evidence of success and the response when reality differs from the design.

A useful next step is to review one live implementation against this principle, identify the largest unowned assumption and turn it into a bounded improvement with a measurable outcome.