What does the Pact Broker store that a shared folder of pact files cannot?
answer
- More than a file store
- Applications, versions, pacts, results
- Results attributed to a version pair
- Commit sha is the join key
- It records; it never verifies
basics
~20 sThe Pact Broker stores pacts as a relation: each pact belongs to a named application and a specific version, and each verification result is recorded against that pact and the provider version that ran it. A folder stores only bytes.
solid answer
~50 sA shared folder holds pact JSON documents with no identity and no history. The Pact Broker turns the same documents into a small graph of four things: a **pacticipant** (a named application such as a depot scheduler or its telemetry provider), a **pacticipant version** (the string you publish under, normally the git commit sha, carrying a branch), the **pact** published for that version, and the **verification result** recorded against that pact by a named provider version. Because verification outcomes are attributed to a *pair* of versions, the broker can answer questions no folder can: has this exact consumer version been verified by the provider version currently running in production, did the contract content actually change on this build, and which pacts should a provider fetch to verify. The broker never runs the tests; it records what the provider's build publishes back.
code
bash · 5 linespact-broker publish ./build/pacts \
--consumer-app-version=3f9a1c2 \
--branch=main \
--build-url=$CI_BUILD_URL \
--broker-base-url=$PACT_BROKER_BASE_URLgo deeper
Recall that a pact is a JSON file produced by the consumer's test run, and that a broker is the shared service teams publish those files to instead of emailing them around.
Be ready to name the four things the Pact Broker relates — application, application version, pact, verification result — and to explain why the application version should be the git commit sha.
An interviewer expects you to explain what the relation makes answerable in production: which consumer versions a provider should verify, and why a pact with no verification result is unknown rather than safe.
Own the argument for the broker as shared system of record across teams: it moves compatibility evidence out of individual pipelines into one place that later gates, selectors and audits can query.
## A pact file on its own is a snapshot A pact file is a JSON document produced by a consumer's test run: a consumer name, a provider name, and a list of interactions with their expected requests and responses. It is a perfectly good artefact and a perfectly bad system of record. Drop forty of them in a shared bucket and you cannot say which build produced which file, whether the file has changed since anyone last looked at it, or whether any provider has ever replayed it successfully. The file carries expectations; it carries no evidence. The Pact Broker is not a nicer folder. It is a small relational model over the same documents, and the relation is the whole point. ## The four things the broker relates 1. **Pacticipant** — a named application that takes part in contracts, for example a depot scheduler and a tram-telemetry service. It is a stable identity that outlives any single build. 2. **Pacticipant version** — one version of that application, identified by the string you publish under (`--consumer-app-version` on `pact-broker publish`). A version can carry a **branch**, so the broker knows a pact came from a feature branch rather than the main line. 3. **Pact** — the contract content published *for* a pacticipant version, between one consumer and one provider. The broker deduplicates identical content, so it knows whether the forty-one interactions in a depot scheduler's pact actually changed between two commits or were merely re-published unchanged. 4. **Verification result** — a success or failure record, attributed to a specific **provider version**, against a specific pact. This is the row that converts two independent facts into a relation, and it exists only because the provider's verification run publishes it back. ## What the relation makes answerable | Question | Shared folder | Pact Broker | |---|---|---| | Which build produced this pact? | Unknown | The pacticipant version, with its branch | | Did the contract content change on this build? | Diff two files by hand | Recorded; drives content-changed webhooks | | Has provider version `9d41e0` verified consumer version `3f9a1c2`? | Unknowable | A row in the verification matrix | | Which pacts should this provider verify right now? | Every file present | A query — for example the pacts of the consumer versions currently deployed or released | | Is it safe to release this version? | Guesswork | `can-i-deploy` reads the matrix | The last two are the ones that change how teams work. A provider verifying "every pact in the folder" is verifying the expectations of consumer versions that were deleted months ago and consumer branches nobody merged. A provider verifying against selectors — the pacts of consumer versions on the main branch, or the ones recorded as deployed to production — is verifying against reality, and it can only do that because the broker knows which versions those are. ## What the broker deliberately does not do - **It does not run any tests.** Verification happens in the provider's own build; the broker stores the outcome that build reports. A pact sitting in the broker with no verification result is not "passing", it is unverified. - **It does not judge whether the pact is a good contract.** Content quality is a review concern, not a broker concern. - **It does not know what is deployed.** Something has to tell it, by recording a deployment or a release of a version to an environment. Until then the broker knows every version that ever existed and nothing about which are live. - **It does not merge contracts.** Two consumers of the same provider produce two separate pacts, each verified on its own. ## Consequences for how you publish Because the version string is the join key of the whole model, it has to be the identity of the artefact you will actually deploy — the git commit sha, or a build identifier derived from it. Publishing every build under `latest`, a timestamp, or the branch name collapses the relation: verification results pile up against a version string that means something different every hour, and any later question about "this version" has no honest answer. The practical rules that follow are short. Publish on every consumer build, not only on main, and pass the branch so the broker can tell feature work from the main line. Use the commit sha as the application version on both sides. Have the provider publish verification results on every verification run, including failures — a missing result and a failed result are different facts, and only one of them means someone looked. Seen this way, the broker is the shared memory two teams cannot keep in their heads: who expects what, who has proved it, and at which versions each of those was true.
- Why does using the git commit sha as the application version matter to the Pact Broker specifically?The version string is the join key of the broker's model: pacts, branches, verification results and environment records all hang off it. If it is the sha of the artefact you deploy, every later question resolves to a real build. If it is `latest` or a timestamp, verification results accumulate against a label whose meaning changes, and the broker can no longer say which code was proved compatible.
- A pact sits in the broker with no verification result at all. What does that state mean?It means nobody has looked. It is not a pass and not a fail — the provider has never replayed those interactions, or ran them and never published the outcome. Deployability checks treat it as unknown rather than safe, which is why providers should publish results on every verification run, failures included.
- Two consumers depend on the same provider. What does the broker hold for them?Two separate pacts, one per consumer-provider pair, each with its own publication history and its own verification results per provider version. The broker never merges them into a single contract, so one consumer's new expectation cannot silently change what the other consumer is asserted to need.
A folder of pact files is a stack of unsigned contracts; the broker is the registry that also records who countersigned which copy, and when.
saying these in an interview costs you the question
- Calls the broker a file server for pact JSON
- Thinks the broker runs the provider's verification tests
- Publishes every consumer build under the version 'latest'
- Assumes a pact present in the broker is a passing pact
- Cannot say where verification results come from
- Believes the broker knows what is deployed without being told