The tax portal's invoice service hard-codes direct HTTPS calls and shared database tables into the payment service, so either team's change breaks the other at deploy time. What problem is this, and what direction improves it?

When the tax portal’s invoice service hard-codes direct HTTPS calls and shared database tables into the payment service so either team’s change breaks the other at deploy time, the problem is tight coupling. The improvement direction is to loosen coupling with messaging or well-versioned APIs so each service can deploy independently. Shared tables create invisible contracts: a column rename in payment breaks invoice queries without a compile error. Synchronous hard-wired calls create temporal coupling: payment downtime becomes invoice downtime. Municipal finance teams need release independence when ordinance changes hit fee logic on a different calendar than payment-provider updates.

Calling the situation “loose coupling” and merging both services into one binary strengthens coupling rather than fixing it. Claiming shared tables guarantee independent deployability inverts the truth—shared schemas are a primary coupling mechanism. Labeling it an orchestration anti-pattern fixed only by deleting API Gateway misdiagnoses the issue; orchestration is unrelated, and API Gateway is not the coupling culprit.

Exam caveat: some synchronous calls remain appropriate for request/response lookups; the anti-pattern is unmanaged, version-hostile, schema-sharing entanglement that blocks independent deploys. “Looser” does not require abandoning consistency controls—use events, outboxes, or explicit API versions deliberately.

Operational check: inventory cross-service table access and replace with APIs or events; introduce versioned contracts and consumer-driven tests; measure whether invoice can deploy while payment is frozen; and add integration tests that fail when undocumented shared-schema assumptions creep back.