Cross-team API changes are the real latency in microservices, and it is measured in weeks. Nobody puts that number on a dashboard because it does not show up in any trace, any p99, any APM tool. The network call is fast. The thing that is slow never touches the network at all.
The mechanism
Say you need one new field on an order object returned by another team's service. Maybe it is a discountCode, maybe it is a fulfillmentCenterId, does not matter. What matters is who owns the schema.
In a monolith, that field lives in a shared model. You open a PR, a teammate reviews it, it merges by lunch. One commit, one deploy, done.
Across a service boundary, the field lives in a service you do not control. The sequence looks like this:
- You message the owning team, or file a ticket.
- The ticket sits in their backlog until their next planning session.
- Someone on that team estimates it, prioritizes it against their own roadmap, and schedules it.
- They write the PR, review it, and ship it, on their timeline, not yours.
- You write your own PR to consume the new field, once it exists.
Two weeks if the owning team is fast and the field is trivial. A quarter if it competes with their own sprint commitments, which it usually does, because your one field is nobody's priority but yours.
It is not a network problem
The instinct is to treat this as a technical latency problem, the same category as a slow query or a chatty API. It gets a technical response: better documentation, faster CI, an internal API gateway, more automation around service discovery.
None of that touches the actual bottleneck. The request-response cycle between the two services takes milliseconds whether the field exists or not. The delay lives entirely in the gap between "we filed the ask" and "the owning team scheduled the work." That gap is a queue, and it is a queue that belongs to a team whose backlog you have no authority over.
This is the part people miss: microservices did not introduce a network problem into your architecture. They introduced an organizational dependency graph, and every edge in that graph now has to be negotiated instead of just written. A monolith's "dependency" is a function call. A microservices "dependency" is a relationship between two teams' roadmaps.
A concrete version of the problem
Picture a checkout service that needs a loyaltyTier field from the customer service to compute a discount correctly. The checkout team does not own customer service. They file a request.
Ticket: Add `loyaltyTier` (enum: BRONZE, SILVER, GOLD) to GET /customers/{id}
Requested by: checkout-team
Priority: P2 (their P2, not yours)
Status: backlog
The checkout team cannot ship their discount logic until this lands. They are not blocked by a database, a deploy pipeline, or a load balancer. They are blocked by another team's sprint board. If the customer team is mid-migration, or short-staffed, or simply has three P1s ahead of it, the checkout team waits. There is no retry, no timeout, no circuit breaker for an organizational queue.
The honest trade-off
There are real fixes for this, and every one of them costs something up front. None of them are free lunches, and anyone pitching one as a strict win is skipping the cost column.
Embed a rep from the consuming team in the owning team's planning. This buys real speed: the field gets prioritized because a human advocating for it is sitting in the room. It costs headcount. Someone's calendar now has a recurring meeting with a team they do not report to, and someone's manager has to sign off on that time.
Go contract-first with a schema registry. Define the contract before either side writes code, validate changes against it in CI, and both teams catch breaking changes before they ship instead of after. This buys predictability. It costs discipline: every team touching the registry has to actually write contracts before code, review schema diffs like they review code diffs, and resist the shortcut of just shipping a field because it is faster this one time.
Build self-serve schema evolution for optional, additive fields. Let consuming teams add new optional fields to a schema without a round trip through the owning team's backlog, gated by validation rather than a human approval queue. This cuts the wait to near zero for the common case. It costs governance: someone has to build the tooling, define what counts as safely additive versus breaking, and maintain the guardrails so "self-serve" does not turn into "anyone can silently change the contract."
None of these fixes are cheap. All of them beat waiting a quarter for one field.
What actually changes
Adding a field is not slow because computers are slow. It is slow because prioritization is a human process, and cross-team prioritization has no SLA. The teams that ship fast across service boundaries are not the ones with the fastest network. They are the ones who paid the coordination cost before they needed the field, not after.
How long does a one-field ask actually take to land across a team boundary where you work, and which of these fixes, if any, does your org already run?
Top comments (0)