Zhivko Todorov
ALL CASE STUDIES

CASE 61 · LYRIC · 2025

ALB WEIGHTEDCANARYCODE DEPLOYBLUE/GREEN

Deploys that the customer doesn’t notice. Not even the canary one.

A consumer mobile app had a deployment process that took the API into degraded mode for 20-30 seconds during each release, three times a day. Players noticed; reviews complained. We replaced it with ALB-weighted canaries and blue/green deploys that don’t touch the served traffic shape.

INDUSTRY

Consumer mobile

DOMAIN

RELIABILITY

DELIVERED

2025

STACK

APPLICATION LOAD BALANCER·CODEDEPLOY·ECS FARGATE·CLOUDWATCH ALARMS·X-RAY·EVENTBRIDGE

RESULTS

What changed, by the numbers.

DEPLOY-INDUCED DEGRADATION

0s

WAS 25s × 3 / DAY

CANARY DETECTION

< 90s

BAD-DEPLOY ROLLBACK

PLAYER COMPLAINTS

−96%

POST-DEPLOY SUBSET

DEPLOYS / DAY

3 → 7

NO LONGER FEARED

HOW IT WENT

The 25-second degradation came from the deploy strategy: drain connections, replace tasks, drain again. In aggregate the API was fine; for the unlucky players whose request landed during the swap, the connection got reset and the app retried.

We replaced it with ALB-weighted blue/green: green provisioned alongside blue, weighted traffic gradually shifted from 100/0 to 95/5 (canary), then 80/20, 50/50, and so on. CloudWatch alarms on error rate and latency could halt the rollout. CodeDeploy orchestrated the whole thing.

Deploy-induced degradation dropped to zero — measurable in monitoring, invisible to players. Bad-deploy detection lands inside 90 seconds via the canary alarms. Deploy frequency more than doubled because nobody fears the deploy anymore. The app store rating recovered.

READY WHEN YOU ARE

Let's get your AWS bill (and architecture) in order.

The discovery call is free. You walk away with at least one concrete idea — even if we never work together.

Or email directly →