When is asynchronous data flow worth making the default style for every new service across several teams?
answer
- portfolio decision, not service decision
- benefit per service, cost per team
- carrying two models is the real tax
- write the qualifying test down
- state what would reverse it
basics
~20 sOnly when most of the portfolio has the qualifying workload and the dependencies can be reached without parking a worker. The costs land on people and are largely fixed per team, so they amortise when the style is everywhere and multiply when it is a minority.
solid answer
~40 sThis is a portfolio decision, not a service decision. The benefit accrues per service and only to services with high in-flight concurrency dominated by waiting, while the costs — learning a second model of control flow, tracing across worker hand-offs, reviewing unfamiliar failure modes — land on the team and are paid whether or not that service collects anything. A codebase carrying two concurrency models pays for both: two sets of tooling, two review habits, every engineer holding both. So default it when a clear majority of new services qualify and the dependency ecosystem supports it; otherwise keep it an exception with a written qualifying test, concentrate the expertise, and accept the two-model tax on the few that need it. Then write down the evidence that would reverse the call.
go deeper
The takeaway is that a house style is a decision about people as much as machines. A style nobody on the team can debug is a cost even when the code is correct.
Notice where the benefit and the cost land. Capacity is collected by the service that qualifies; learning, tracing and review are paid by everyone on the team regardless.
Argue from the workload distribution across the portfolio, and insist that the qualifying test is written down so the next service is decided on evidence rather than advocacy.
Own the reversibility. Size the bet to what you can withdraw, fund tooling and teaching as preconditions, and record in advance the measurements that would tell you a year from now that the call was wrong.
## Why the unit of decision is the portfolio Asked service by service, this question has an easy answer: adopt the style where the workload qualifies. Asked as a standard for many teams, it becomes harder, because **the benefit and the cost land on different things**. - The **benefit is per service** and conditional: capacity reclaimed from parked workers, collected only where concurrency is high, waiting dominates, and the dependencies release their workers. - The **cost is per engineer and per codebase**, and largely fixed: learning a second model of control flow, tracing a request across worker hand-offs, recognising failure modes that do not exist in sequential code, reviewing them competently. A standard set across teams therefore multiplies a fixed cost by headcount, in exchange for a conditional benefit collected by a subset of services. That is the shape of the bet. ## The tax nobody puts in the proposal The cost that decides most of these arguments is not the style itself — it is **carrying two of them**. A portfolio where some services are sequential and some are asynchronous pays: - Two sets of debugging habits, and engineers who must know which one applies before they can read a failure. - Two tracing and context-propagation setups, since carrying per-request data across worker hand-offs is not inherited from the sequential case. - Reviewers who are fluent in one and hesitant in the other, which quietly slows the services they are hesitant about. - Mobility friction: an engineer moving between teams arrives fluent or does not. That tax cuts both ways, and it is the honest argument *for* standardising as well as against: if the style is going to exist in the portfolio at all, concentrating it is cheaper than sprinkling it. ## The two credible standards | | Default everywhere | Exception with a written test | |---|---|---| | Fits when | Most new services qualify | A minority qualify | | Onboarding | One model, taught once | Two models, one taught on arrival | | Cost on simple services | Paid with no benefit | Not paid | | Expertise | Spread thin across everyone | Concentrated in one or two teams | | Failure if wrong | Every service taxed | A capability gap when a new case appears | The second column is the right answer far more often than teams expect, and it is only workable if the qualifying test is **written down** — something like: many long-lived connections mostly idle, or a response that is an open-ended sequence, or fan-out dominating a request's lifetime, *and* a dependency inventory that converts. Without a written test, "exception" degrades into whoever argues most confidently. ## Preconditions for choosing the default Even where the workloads qualify, three things must hold before making it the house style: 1. **The dependencies convert.** If the clients your teams must call cannot be reached without parking a worker, the default imposes the cost and withholds the benefit. 2. **The tooling is funded first.** Tracing across hand-offs and carrying per-request context are prerequisites, not follow-ups. Standardising before they exist makes every team build them badly, separately. 3. **Teaching is resourced.** A house style that half the engineers cannot debug is not a standard, it is a bottleneck with a policy attached. ## Sizing the bet to its reversibility A standard is easy to announce and expensive to withdraw, because each service written under it is a rewrite to undo. That asymmetry argues for entering through a small number of services that genuinely qualify, and for stating in advance what would count as the decision going wrong: - Time for a new joiner to make their first safe change, compared before and after. - Incidents whose cause is the style rather than the domain. - Services converted that later showed **no measurable capacity gain** — the clearest sign the qualifying test is too loose or unused. - Whether the expertise stayed concentrated or spread as intended. ## What a strong answer sounds like It refuses the framing that this is a technology preference. It separates conditional per-service benefit from fixed per-team cost, names the two-model tax explicitly, proposes a written qualifying test rather than a blanket rule, makes the tooling a precondition, and finishes with the evidence that would reverse the call in a year. A weak answer generalises from one flagship service that benefited, and mentions nothing that would ever change its mind.
- Only two services in a portfolio of twenty qualify. What is the standard?Keep the style an exception. Write the qualifying test down so the next case is argued on workload rather than enthusiasm, concentrate the expertise in the team that owns those two services, fund the tracing they need, and accept that a new joiner does not start there. Taxing eighteen services to make the portfolio uniform is the expensive mistake here.
- A year after making it the default, how would you know it was wrong?Measure the things the decision claimed. How long a new joiner takes to make a safe change, how many incidents trace to the style rather than the domain, and how many converted services show no measurable capacity gain. That last one is decisive: it means the qualifying test is too loose or is not being applied.
- Does concentrating the expertise create its own risk?Yes — a bus-factor and a bottleneck, since the services that need the style depend on a narrow group for review and incident response. Manage it deliberately: more than one person fluent per qualifying service, written runbooks for its distinctive failure modes, and rotation into that team. It is a smaller risk than an untrained portfolio, not an absent one.
saying these in an interview costs you the question
- Standardises because one flagship service benefited from the style.
- Treats the decision as per-service when the costs land on teams.
- Ignores that carrying two concurrency models is itself a cost.
- Names no evidence that would reverse the decision later.
- Announces the standard before tracing and training exist.
- Frames the choice as modern versus legacy rather than fit versus cost.