You’re shipping a rewrite of your checkout write path on Friday.
Node.js on ECS Fargate. ~3,000 RPS at peak. Postgres with row-level locking on the orders table. The change touches the line of code that actually charges the customer’s card — old path uses Stripe Charges API, new path uses PaymentIntents with 3DS.
The QA env is green. Load test passed. Your staff engineer signs off.
But it’s checkout. If this breaks, money breaks. And you can’t roll back a card that already got charged.
Pick the deploy strategy:
A) Blue/Green — spin up a parallel “green” environment running the new code, smoke-test it, flip the load balancer. Instant rollback by flipping back.
B) Canary — route 1% of live traffic to the new version, watch error rates and p99 latency for 30 minutes, then ramp 5% → 25% → 100%.
C) Rolling — replace ECS tasks one at a time. Old and new versions serve traffic side-by-side until the new version is fully rolled out.
D) Feature Flag — deploy the new code to 100% of tasks behind a flag defaulting to OFF. Then flip the flag for internal users → 1% of customers → 10% → 100%, with an instant kill switch.
All four are real production patterns. Three of them have a subtle hole when the change touches money.
Pick one — A, B, C, or D — and tell me why. Full breakdown in the comments.
If your team has ever argued about this on a Friday at 4pm, share this with them. The debate is the whole point.
Drop your answer 👇
#30DaysOfSystemDesign #SystemDesign #DevOps #SoftwareArchitecture

Smiley Face

Joud Awad

A system design challenge exploring deployment strategies for a high-stakes checkout rewrite touching payment processing code. The scenario involves Node.js on ECS Fargate at ~3,000 RPS, migrating from Stripe Charges API to PaymentIntents with 3DS. Four strategies are presented — Blue/Green, Canary, Rolling, and Feature Flag — with the key insight that three of them have subtle flaws when the change involves irreversible financial transactions like card charges.

14/30 Days System Design Questions!

Answer: D — Feature Flag ✅
Here’s why, and why the other three look right but quietly fail when the change touches money:
Why D wins (Feature Flag):
Feature flags decouple deploy from release. The new code ships to 100% of your ECS tasks — but it’s dormant. Nothing executes until you flip the flag.
• Rollback is a config push, not a deploy. Sub-second. No ECS restarts, no LB drain, no DNS TTL.
• You target who sees the new path, not what % of random traffic. $0.99 customer and $40K B2B customer shouldn’t get coin-flipped equally — that’s not a strategy, that’s hope.
• You can keep the old code path warm for weeks. 3DS edge case on a specific issuing bank in Brazil? Flip those users back while keeping everyone else on v2.
<img src="https://media.daily.dev/image/upload/s--SvnyxOgX--/f_auto/v1779207843/ugc/content_decf9308-36fe-4407-a273-ce7e7ca40443?_a=BAMAMiWQ0" alt="14-days-system-design-questions-answer.png">

Why C is wrong (Rolling):
For 5–10 minutes, old and new tasks serve checkout simultaneously. “Create order” hits v1. “Confirm payment” webhook 800ms later hits v2. Inconsistent state written by code that was never tested together.

Why B is the trap (Canary):
<ol>
<li>Canary routes by request, not by customer. A B2B billing job hits your 1% canary 50 times in an hour. Bug on their card type? You’ve charged them 50 times before dashboards catch it.</li>
<li>Payment failures don’t surface as 5xx errors — they surface as successful 200s that charged the wrong amount. Your error-rate alarm never fires.</li>
</ol>

Why A is wrong (Blue/Green):
“Instant cutover” is the problem. The moment you flip the LB, 100% of live traffic hits new code — including Stripe webhooks confirming PaymentIntents created by the old code. Cross-version race condition on real money. Rollback doesn’t undo a charge.

In practice how do you implement the feature flag without redeploying the ECS tasks? Say the flag is saved as environment variable after you changed it don’t you need to force new deployment?