AWS Microservice Infrastructure and Integration

Subledger Technology platform inside Asset & Wealth Management. The wider platform spans on-prem and multi-region AWS; this work focused on the AWS-native microservices slice and its supporting infrastructure-as-code, not on owning the broader platform.

New services needed a consistent, repeatable way to ship on AWS - networking, container runtime, database access, auth, and tests - without each team re-inventing the deployment shape per service.

• Everything provisioned through code review, not the AWS console
• Services had to fit a hybrid model that spans on-prem and multi-region AWS
• Database access patterns had to suit a financial workload (durability, predictable failover)
• Integration tests had to run in CI against a representative environment, not against mocks only

Contributed to

Implemented and contributed to defined service infrastructure and integration components using TypeScript CDK, ECS Fargate, Aurora PostgreSQL and Lambda.

• Defined service infrastructure in TypeScript CDK so reviewers could read the deployment shape in the same pull request as the code
• Ran services on ECS Fargate to avoid managing EC2 capacity and to keep deployments declarative
• Used Aurora PostgreSQL as the system of record, with schema and access patterns expressed through migrations
• Used Lambda for event-driven and asynchronous edges where running a long-lived container was overkill
• Wired routing and auth into the gateway layer as IaC rather than per-service ad-hoc configuration
• Added integration tests that exercise real AWS resources from CI to catch wiring mistakes before promotion

• Console-driven networking, gateway routing, and auth configuration (faster initially, but invisible to source control and prone to drift between environments)
• Plain CloudFormation YAML instead of CDK (works, but loses the type-checking and shared abstractions that make TypeScript CDK reviewable across teams)
• Running services on EC2 instead of ECS Fargate (more control, but adds capacity management without a clear benefit for this workload)

• Cold-start behaviour for Lambda paths on the asynchronous edges
• Aurora failover behaviour during planned maintenance windows
• Integration tests that passed in CI but pointed at a misconfigured environment resource
• Gateway routes that worked in one region but not another because of a region-scoped IaC parameter

• AWS
• AWS CDK (TypeScript)
• ECS Fargate
• Aurora PostgreSQL
• AWS Lambda
• API Gateway

• Keeping the AWS-native slice consistent with on-prem services in the hybrid model
• Making integration tests against real AWS resources reliable enough to gate releases
• Encoding routing and auth as IaC without making service authors' day-to-day changes painful

Services in the scope I contributed to landed with a consistent, reviewable deployment shape on AWS, and routing, auth, and integration tests lived alongside the service code in version control rather than in console configuration.

Infrastructure that is reviewable in the same diff as the code is easier to reason about than infrastructure managed in a console, particularly when the same change has to ship across regions.

I would invest more in a shared CDK construct library that captures the routing, auth, and integration-test scaffolding as one reusable unit, so a new service can opt into the platform defaults with a few lines instead of copying patterns across stacks.