For a service with a database, a message broker and two downstream HTTP dependencies, where do you draw the integration test boundary?

What the interviewer is testing

Whether you can reason about test scope by defect class and cost rather than reaching for a label.

The recommended boundary

Real database, real broker, stubbed HTTP dependencies.

Real database because the highest-value defect class in most services lives there: queries, migrations, transaction semantics, isolation behaviour, constraint violations, mapping errors. Containerised databases made this cheap enough that using an in-memory substitute is hard to justify — the substitute has different SQL semantics, different transaction behaviour and a different query planner, so it verifies code against a database you do not run.

Real broker because serialisation, partitioning, consumer group behaviour, acknowledgement and redelivery are where messaging defects live, and they are not reproducible against a mock.

Stubbed HTTP dependencies because they are owned by other teams. Calling them live makes your test suite's reliability a function of their availability, and it does not test their correctness — that is what contract tests are for, and the stubs should be generated from those verified contracts rather than hand-written.

The general rule

Put the boundary just outside the code you own. Everything inside is real; everything owned by another team is a contract.

What must still exist outside this boundary

Contract tests against each HTTP dependency, so the stubs are trustworthy. And a small end-to-end set covering the journeys where the sequence across services is the risk.

What a strong answer adds

Stopping the argument about what "integration test" means by stating the boundary explicitly instead — which components are real and which are replaced. Teams routinely argue past each other because the term covers everything from a two-class test to a full-system run.

And noting the cost inflection: two services together is where value begins to fall behind cost, and where contract tests are the better instrument.

Common weak answers

Everything real, which is an end-to-end test with a different name. Everything mocked, which tests the mocks.