advanced 2 min answer Multiple choice

Two teams argue: one wants a shared integration environment running all services, the other wants contract testing. Adjudicate.

contract-testingintegrationmicroservices
Pick one
Show the full answer Hide the answer

What the interviewer is testing

Whether you understand the scaling property that decides this, rather than treating it as a preference.

The scaling argument

A shared integration environment's cost grows combinatorially: every service added increases the ways the environment can be broken, and every test depends on every service being deployed, healthy and in a compatible version. Past a modest number of services it is broken more often than not, and its results become uninterpretable — a failure means something is wrong somewhere.

Contract testing costs grow linearly. Each consumer records what it needs; the provider's pipeline verifies those expectations at unit-test speed. No environment, no coordination.

Crucially, contract testing gives faster and more precise feedback: the provider's build fails, before deployment, naming the consumer and the expectation.

What contract testing does not cover

Be honest about this, because it is where the shared-environment argument has its legitimate core:

  • Semantic compatibility — the field is present and correctly typed and now means something different. No schema check detects it.
  • Multi-service business flows where the value emerges from the sequence.
  • Consumers who have not written contracts, including third parties.
  • Emergent behaviour — timeouts, retries, performance under real interaction.

The adjudication

Contracts replace the great majority of inter-service integration testing. A small curated end-to-end set covers the critical journeys where sequence matters. And production verification — canary analysis and synthetic journeys — covers emergent behaviour with better fidelity than any pre-production environment can.

Keeping one production-like environment for periodic full-system rehearsal is reasonable. Keeping it in the path of every change is not.

What a strong answer adds

The operational requirements at scale: can-I-deploy checks querying whether this version's contracts are verified against what is actually deployed in the target environment, and contract pruning, since consumers accumulate expectations for fields they no longer use and each one needlessly constrains the provider.

Common weak answers

"Both" without noticing that the shared environment's cost is the whole objection. Contract testing presented as covering everything.