Challenge

An interactive voice response (IVR) call moves through several transaction steps while preserving caller context between requests. The platform needed to coordinate inquiries and validation, translate transaction responses, and return the next action in the call flow.

My contribution

I designed and deployed the IVR API and service architecture using API Gateway, Step Functions, Lambda, and ECS, with GitOps deployments. The service implementation combined Java Lambdas, a Node.js cache-management Lambda, data-access components, and Redis call state.

System overview

The service layer supports DNIS and station inquiries, ID and MICR validation, Code 10 handling, authorization-related processing, and decline inquiries. A response generator maps core authorization outcomes into IVR-facing responses and consults the data-access layer for the next action.

Simplified view of IVR service responsibilities and dependencies. It does not prescribe a production orchestration sequence.
Simplified view of IVR service responsibilities and dependencies. It does not prescribe a production orchestration sequence.

Text description: IVR service handlers process requests. Cache management uses Redis to preserve call context. Response generation uses Oracle data access and updates call state. These are service responsibilities, not a fixed ordering of calls.

Redis carries request context, prompt indicators, and current and next actions between requests. Database and Redis credentials are retrieved through Secrets Manager. The Java response generator includes SnapStart checkpoint and restore hooks for preparing and reconnecting database and cache dependencies. CloudWatch logging permissions and X-Ray instrumentation support operational visibility.

Outcomes

Delivered a modular IVR API supporting transaction inquiries, validation, response generation, and stateful call progression.

Engineering considerations

Stateless compute still needs a consistent approach to call state. Cache expiry, connection recovery, and response mapping affect whether a caller can continue successfully. SnapStart also requires connection lifecycle handling: restoring an execution environment does not guarantee that an existing external connection remains usable.

Supporting examples

Related learning material demonstrating serverless security and operations:

Discuss a similar challenge