Decoupling a forms-processing service from the CMS it happened to run next to

A forms-processing microservice was tightly coupled to the Sitecore/EKS cluster: a slow Sitecore server degraded it too, any change to the microservice's code required a full Sitecore deployment, and the client had already decided to migrate the front end from Sitecore to AEM.

Rearchitected the service as a stateless, serverless, event-driven system on AWS Lambda (.NET 10) with EventBridge, keeping its REST interface for submissions but dropping any session-state dependency, so it processes form data independently of whichever CMS sits in front of it.

Architected the microservices topology and the event-driven integration layer, including the decision to decouple it entirely from the CMS's own infrastructure lifecycle.

Considered SQS/SNS for the queuing layer, but discarded it: a retry mechanism already existed, and a second retry queue on top would have been redundant. With the Sitecore-to-AEM migration already decided, staying platform-agnostic mattered more than optimizing for the CMS currently in place, which ruled out any design that stayed coupled to Sitecore's own infrastructure.

15+ independently deployable services, deployment time cut from 3+ hours to under 10 minutes (IIS to Lambda), 2x traffic growth absorbed with zero downtime, and a service architecture that no longer depends on any single CMS platform's infrastructure or release cycle.