Spring Boot project: define the receipt service release boundary

Assemble a disposable rehearsal

Start from the last released schema on the intended database engine. Launch the old application version, apply the nullable expansion, then launch the new version. Keep both alive while reading and writing. Backfill from an authoritative tenant source; only after old writers leave should the NOT NULL phase run. The H2 migration project checks a sequential subset, not this live overlap.

Give the new version its actual environment variables and required imported files. Record redacted effective values. Route it behind the intended proxy, withdraw readiness and terminate it while one accepted request runs. The stop lesson names the response ambiguity that must be handled with a stable request identity.

Count recovery, not just success

Allow the relay to claim work, then kill it after the consumer commits but before acknowledgement. A replacement must wait for lease expiry, retry with the same event ID and avoid a second mutation. The local fake-transport fixture checks the state transition; this project requires a real broker and target database to establish the release behavior.

The source kit is still a teaching artifact. ReceiptApplication has fixture Basic credentials, in-memory receipts and no runtime Flyway or scheduler. Promote each dependency only after the corresponding integration test exists. Keep the full failure trace and timing measurements with the release candidate.

Working sketch

schema V1 -> nullable V2 -> old/new overlap -> verified backfill -> old retired -> V3
traffic admitted -> readiness withdrawn -> in-flight request resolved -> process stopped
claim -> publish -> consumer commit -> lost ack -> lease expiry -> deduplicated replay

Verification boundary

This is a project plan assembled from local fixtures; no end-to-end release rehearsal has run.

Costs and limits

Target database, issuer, broker, proxy, deployment platform and mixed-version processes are not supplied by the kit.

Common Mistakes

• Do not present a sequence diagram as an executed rollout.
• Do not contract a column while an old writer still omits it.
• Do not infer durable recovery from a fake transport and one H2 process.

Read next

Spring Boot project: test a versioned receipt schema before choosing deployment ownership, Spring receipt delivery project: atomic write, guarded claim and replay, Spring Boot graceful shutdown: finish accepted requests within a deadline, Spring release tests: distinguish context checks from process and platform checks.