Strangling a benefits monolith without stopping enrollment

Eligibility & Enrollment was a tightly coupled monolith: shared data, synchronous integrations, and batch jobs that were hard to change without risking daily operations. The migration did not start with a rewrite. It started with a map.

We used domain-driven boundaries — Customer Service, Worker Portal, Sampling, Notices, QC, and a reusable batch framework — and moved capability with a Strangler Fig approach. Adapter, facade, and anti-corruption layers kept legacy interfaces from dictating every new service. REST contracts made data ownership and versioning explicit.

Two infrastructure choices mattered as much as the domain model. Large application and batch files now go to S3 with short-lived pre-signed URLs; application servers never held the payload. S3 events, SQS, and Lambda continue validation after upload, with PostgreSQL tracking object keys, status, retries, and audit history. Idempotency and dead-letter handling were not extras. They were how you keep a strangler from creating a second outage mode.

Batch moved to a parameterized, chunk-oriented, restartable Spring Batch framework, orchestrated with Apache DolphinScheduler. The UI moved from Angular 10 to 16 on the same program of work. Spring Boot itself moved from 2.7 toward 3.x.

If you are planning a similar migration: spend time on the shared database and the batch calendar before you celebrate the first extracted service. That is where enrollment actually lives.