Diagnose services that still require lockstep releases

Understand the likely causes

• Potential causes include provider-specific types in public interfaces, a shared database schema used as an undocumented contract, enum changes that old consumers reject, and ownership split across a single invariant. These are competing hypotheses; the symptom does not by itself prove that services should be merged.

Map one real change across the boundary

Choose a recent synthetic change and list the edits it required, the reason for each edit, and the release ordering constraint. Separate legitimate product coordination from technical lockstep dependency. If a notification template change edits seat-allocation policy, inspect the shared types or implicit behavior connecting them. Preserve exact field meanings and error cases rather than reducing the investigation to repository counts. The goal is to identify the smallest coupling mechanism that explains the coordinated release.

Change: introduce notification channel display name
Unexpected edit: booking imports provider Channel enum
Release constraint: old booking rejects a new enum value
Hypothesis: provider vocabulary leaked into the booking contract

Check old and new combinations explicitly

Build a compatibility matrix for old caller with new provider and new caller with old provider. Include unknown fields, missing optional fields, error codes, and any newly introduced values. Determine whether the contract promises tolerant parsing or exhaustive interpretation. A successful new-with-new test misses the mixed versions that rolling releases create. Use isolated fixtures; this guide performs no application deployment or service calls. Record the exact consumer version and response fixture when reporting a result.

Inspect the write path as well as the API

An apparently stable API can conceal two applications updating the same columns with different validation rules. Identify the authoritative writer for each business state and the consumers that bypass it. A schema migration may be the true source of release coordination. Do not repair this by adding another shared abstraction without deciding ownership. Introduce a controlled command boundary or an explicitly shared transaction model, then migrate bypasses in stages with verification of the business invariant.

Choose a targeted correction with an exit condition

For leaked provider vocabulary, translate vendor values inside the notification adapter and expose a stable booking-oriented contract. For an inseparable invariant, reconsider whether the boundary should remain local. For a temporary migration overlap, name the remaining direct writers and removal gate. The sample repair note requires evidence before retirement rather than assuming a new interface fixes all coupling. Keep exceptions narrow and owned so the correction does not become another indefinite compatibility layer.

correction: move provider enum translation into notification adapter
public_contract: stable notification intent and outcome
verification: mixed-version consumer fixtures pass
exit_condition: booking no longer imports provider vocabulary

Keep it from recurring

• Review representative cross-boundary changes during architecture upkeep, keep public contracts separate from vendor types, and assign a data owner before introducing another writer. Track why releases coordinate so recurring patterns can challenge the boundary rather than merely improving the release checklist.