~12 min read · updated 2026-05-18

What's next

What this track deliberately didn't cover, and where to go for each piece. The roadmap for the engineer who finished module 31.

The track ends here. What you’ve built is the shape of a real production backend: a Java application, persistence, cache, event bus, identity, gateway, mediator, full-stack observability — nine features riding on top of that platform, three user-facing GUIs (the vanilla HTML/JS tour from module 22, the SvelteKit customer portal, and the React agent dashboard), and the OIDC + HAProxy + BFF wiring that ties it all to a public hostname. Plenty of insurance startups have shipped real customer traffic on less.

About the live-OIDC chapter. If you skipped or skimmed chapter 27, bookmark it. The three load-bearing config bits (the ORIGIN env var on adapter-node, the /oauth2/token issuer suffix, the X-Forwarded-Proto/Host headers from HAProxy) are exactly the three things that derail an OIDC integration the first time you do one on a real public hostname. They generalize beyond WSO2 IS — any framework + any IdP, the same three failure modes turn up.

And about the QA roadmap — it is now all eight phases done. Everything below this line is “next tracks” — things outside the scope of the artifact you just built. The eight-phase roadmap in docs/qa-roadmap.md is complete; all eight milestones are closed (39 issues plus a debt-fix follow-up batch). Of the top-four cheat-sheet items, three are fully green — SAST/SCA scanning in CI, Playwright OIDC tests, and the k6 load baseline (81k requests at 100 VUs, p99 = 41 ms, 0% non-rate-limit errors). The fourth — the third-party pen-test engagement — has its prep doc ready at docs/compliance/pen-test-vendor-prep.md; the actual booking is operator-driven. See chapter 31 for the per-phase outcomes, the three concrete bug-finding loops (Schemathesis → 5 fixes, k6 → VIN length fix, audit-completeness test → 3 missing emissions), and the debt-fix session that closed every deferred dep bump.

What this track didn’t cover is intentional — every omission below is either a separate course or a topic you can deepen alone now that you have the scaffolding.

CI/CD — separate track

Building, scanning, signing, and deploying images belongs to its own course. The expected outline:

  • A Containerfile per service (you have these already).
  • A GitHub Actions or Tekton pipeline that lints, tests, builds the image, scans it, signs it (cosign), publishes to a registry (Quay/GHCR/Harbor).
  • A deploy step against a real environment.
  • Branch protections, required checks, supply-chain attestations.

When the CI/CD track is published, the artifacts from this one are exactly its inputs.

Cloud / OpenShift deployment

Everything here ran on one VM with rootless podman. Real production runs on a Kubernetes-shaped platform. The migration is mostly mechanical once the images exist:

  • Push the images to a registry your cluster can pull from.
  • Write a Helm chart or a Kustomize base per service.
  • Create Deployments, Services, Routes (on OpenShift) or Ingresses.
  • Use OpenShift’s Operator model for stateful services (Postgres, Kafka, SigNoz all have operators).
  • Move secrets from env vars into Secrets or an external secret store.

The hardest parts aren’t the YAML; they’re the operational ones — namespaces, network policies, registry credentials, persistent volumes, autoscaling. A separate track.

Deeper inside the app

Topics that fit into this track but that we’d need a different cadence to do justice to:

  • Domain modeling. The feature chapters (13–22) walk through nine shapes — Quote, Policy, Payment, Notification, Claim, Live claims feed, Reporting, Audit, Search — each with state transitions modeled explicitly. The next level: state machines that the business reads (e.g. Spring Statemachine, or hand-rolled with an enum + transition table), and an explicit policy-document model separated from the policy-state model.
  • Testing. REST Assured for API tests, Testcontainers for integration tests against a real Postgres, Pact for contract tests against APIM-defined contracts. The smoke script in the insurance-app repo (scripts/smoke.sh) is a fine reference for the shape of full-stack tests but doesn’t replace any of the three layers above.
  • Concurrency and transactions. What happens when two requests update the same policy at the same time? The Policy bind feature introduces Redlock for distributed locking; you’ll still want JPA’s @Version for optimistic locking on long-running edits.
  • Schema evolution. Flyway covered the additive case (V1…V7 in the repo). The harder one — adding a NOT-NULL column to a 100M-row table, backfilling, zero-downtime migrations, blue/green schema — was out of scope.

Secrets management

The track left postgres / insurance:insurance in server.xml and the WSO2 IS client secret in env vars. Production replaces both with:

  • HashiCorp Vault (or an alternative like SOPS, Sealed Secrets, External Secrets Operator).
  • Liberty reads the secret through MicroProfile Config with a Vault config source.
  • Secret rotation happens out-of-band; the application reloads on next use.

A standalone module because the choice of secret store cascades into how you deploy (Vault as a container vs. AWS Secrets Manager vs. the platform-provided one).

Service mesh

When you have 8 services talking to each other on one network and you want mTLS, retries, traffic shifting, and authorization policies between services — not at the gateway — you reach for Istio / OSSM or Linkerd. Not relevant until your service count gets above ~10; very relevant once it does.

What I’d build next, in order

The feature chapters gave you the domain model (Policy + Quote + Claim + Payment + Notification + Audit), the vanilla-JS demo tour, and the SvelteKit + React user-facing portals. From here:

  1. Tests at three levels — unit, API (REST Assured), integration (Testcontainers). The smoke script is a starting reference but not a replacement for layered tests.
  2. CI/CD (the other track), all the way to a real environment.
  3. OpenShift deployment — Helm or Kustomize charts per service, the Operators for the stateful pieces (Postgres, Kafka, SigNoz all ship operators).
  4. Per-user filtering on the customer portal — the /account page in chapter 26 calls out this honest limitation. Add a userId column to Policy + Claim, populate it from the X-User-Id header at create time, filter the list endpoints by it. One commit, one migration, real per-user accounts.

By that point the artifact you have is no longer a learning exercise; it’s a starting point for a real product.

Closing

The thing this track tries hardest to teach is not any one tool — it is the layered shape of a real backend: the application is the smallest piece, surrounded by infrastructure that exists to make it useful, with thin user-facing tiers (BFFs, SPAs, server-rendered portals) that hold sessions but not data. Most engineers learn the application code; few have a complete picture of the rest. Now you do.

— End of track. Thirty-three modules across four parts; one platform, nine features, three GUIs (the vanilla tour + the SvelteKit customer portal + the React agent dashboard), the OIDC + HAProxy + BFF spine that holds it together, and an eight-phase roadmap from teaching artifact to production-ready — completed.