( 01 )
At a Glance
The B2B enterprise company operates a mobile-first lending platform that approves small-business and personal loans in minutes. With approximately 350 employees, 1.2 million active borrowers and more than 60,000 loan applications a day, its growth had outpaced its infrastructure.
The platform relied on manually configured servers in a single Availability Zone, while two senior engineers coordinated releases after hours. Over an 18-week engagement, the platform was rebuilt on AWS using containerised services, a resilient database architecture and an automated GitLab CI/CD pipeline, with security checks and controlled production deployments.
( 02)
The Challenge
Four problems were affecting delivery and reliability:
Slow, risky releases: Changes took approximately nine days to reach production, and roughly one in five releases required a manual rollback.
Infrastructure vulnerability: A zone-level outage in 2024 took the loan-approval API offline for more than four hours during a festival-season peak.
Security issues discovered late: Quarterly penetration tests identified vulnerable dependencies weeks after they had reached production.
Data residency and audit requirements: Customer data had to remain in India, with a clear audit trail of infrastructure changes.
The company needed to accelerate releases, improve recovery from infrastructure failures and strengthen security controls without slowing down ongoing feature development.
( 03 )
How we Solved it
A repeatable AWS architecture, designed for resilience
Linnk Innovation Hub deployed a standard three-tier architecture in the company’s own AWS account in the Mumbai Region. The 12 microservices were migrated to Amazon ECS with AWS Fargate and distributed across three Availability Zones, with health-check-based task replacement and auto-scaling.
Amazon RDS for PostgreSQL in a Multi-AZ configuration provided managed database resilience, with automatic failover in under two minutes. Network isolation ensured that application and database tiers accepted traffic only from approved sources, while AWS IAM roles using OpenID Connect (OIDC), AWS Secrets Manager and AWS KMS encryption strengthened access control and data protection.
Centralised logging through Amazon CloudWatch, including VPC Flow Logs and Application Load Balancer logs, improved infrastructure visibility and traceability.
Automated delivery with controlled production releases
A gated GitLab CI/CD pipeline standardised the release process for all services. Each release moved through build, testing, security scanning, packaging and staging before human approval and blue-green deployment to production using AWS CodeDeploy.
Container images were tagged with their commit SHA and promoted through the pipeline without being rebuilt. This ensured that the image tested was the same one deployed to production. Health checks and automated rollback allowed traffic to return to the previous task set if a deployment failed.
Security checks and infrastructure as code
SonarQube quality gates blocked merge requests containing new vulnerabilities or bugs, or failing to meet the required code-coverage threshold of 80%. GitLab Dependency Scanning and Container Scanning identified known vulnerabilities before images reached Amazon ECR
Terraform defined the VPC, ECS, Application Load Balancer and RDS infrastructure, with changes managed through reviewed merge requests. Together with centralised logging and controlled approvals, this created a traceable record of infrastructure changes and release decisions.
( 04 )
How We Delivered It
The 18-week engagement progressed through three phases:
Discovery and proof of concept — 3 weeks: The existing environment was reviewed, compliance requirements were mapped, and the loan-quote service was deployed on ECS in a single environment with a basic pipeline.
Pilot — 5 weeks: The full delivery pipeline, SonarQube quality gate, staging and production environments were established. The loan-quote service began handling 10% of live traffic.
Production rollout — 10 weeks: All 12 services were migrated, high-availability and failover scenarios were tested, and monitoring, operational runbooks and hypercare were handed over to the company’s team.
The migration was carried out service by service using weighted routing on the Application Load Balancer, avoiding a single large cutover. The final service was moved with zero customer-facing downtime.
( 05 )
The Impact
The new delivery process reduced dependence on manual release coordination and gave developers end-to-end ownership of deployments. Releases became more repeatable, while automated rollback and a multi-AZ architecture improved the platform’s ability to recover from infrastructure failures.
Security checks moved earlier into development and release workflows, helping identify vulnerabilities before production. Reviewed infrastructure changes and centralised logs also made operational activity easier to trace.
The operational improvements extended to the team: the on-call rota moved from weekly to fortnightly. Infrastructure changes also reduced staging compute and log and backup storage costs, making the platform more efficient to operate.
( 06 )
The Results
Measured six months after go-live.
|
Metric
|
Before
|
After
|
|---|---|---|
|
Production releases per month
|
2
|
40+
|
|
Commit-to-production lead time
|
Approximately 9 days
|
Approximately 45 minutes
|
|
Releases requiring manual rollback
|
1 in 5
|
Zero. Automated rollback in under 8 minutes
|
|
Recovery from an Availability Zone failure
|
More than 4 hours
|
Approximately 3 minutes
|
|
Critical vulnerabilities reaching production
|
Vulnerabilities identified by quarterly penetration tests, weeks after release
|
Zero during the first six months
|
|
Staging compute costs
|
On-demand virtual machines
|
62% lower, using Fargate Spot
|
|
Log and backup storage costs
|
S3 Standard storage
|
58% lower, using lifecycle policies to Infrequent Access and Glacier
|