Case study · Transaction platform
Monolith to Microservices on AWS ECS
Decomposed a 24+ module transaction monorepo into independently deployable services while preserving external API contracts and workflow orchestration.
All consulting services
Consulting · Cloud & reliability
Design AWS workloads your team can deploy, observe, and secure without heroics.
Most AWS problems I am asked about are not really about AWS. They are about how a team ships: what happens on deploy, who finds out when it breaks, and which secrets are protected by a hardware boundary rather than a policy document. I work on the architecture and the operational practice together, because changing one without the other does not hold.
01Who this is for
Where this work fits
You might recognize
- Teams running containers on ECS, Fargate, or EKS without a deployment story they trust.
- Organizations whose alerting produces noise faster than anyone can triage it.
- Teams handling key material or regulated data who need a hardware trust boundary, not just encryption at rest.
- Platforms where releases depend on one person remembering the right sequence of manual steps.
What it costs you
- Deploys become events that need a calendar invite, so changes batch up and each release gets riskier.
- Alert fatigue means genuine incidents arrive alongside hundreds of monitors nobody reads.
- Secrets protected only by IAM policy leave no answer for "what if the host is compromised?"
- Manual release steps make rollback slow at exactly the moment speed matters most.
02Approach
How the work runs
Start with how code actually reaches production, then change the architecture and the operating practice together.
Start from the deploy path
How code reaches production tells you more about a platform's health than any architecture diagram. I trace one real release end to end before proposing anything.
Make rollout and rollback boring
GitOps pipelines with promotion gates, so shipping is routine and reversing is a parameter flip rather than an incident.
Cut observability down to what gets acted on
Rationalize monitors to the ones that represent real user-visible failure, then route incidents automatically to the team that owns them.
Put a hardware boundary around what deserves one
For key material and regulated data, Nitro Enclaves and KMS allow attestation-bound decryption, so the host operator cannot read plaintext even with full access.
Encode the result as infrastructure-as-code
Terraform and pipeline definitions, so the design survives staff turnover instead of living in someone's console history.
03Tradeoffs
What each choice costs
Every one of these has a downside. Here is what you are accepting and what you get for it.
ECS/Fargate over EKS where it fits
Less control and a smaller ecosystem than Kubernetes. Also far less platform to operate, which for most teams is the difference between a platform they run and one that runs them.
Fewer, louder alerts
You will deliberately stop monitoring things you currently watch. The gain is that a page means something, and on-call stops filtering by instinct.
Confidential computing only where it pays
Enclaves add real build and debugging friction. Worth it for signing keys and regulated data; wasteful for an ordinary web service.
04Deliverables
What you get from a review
Scoped as a focused assessment. Anything beyond this is agreed before it starts, not assumed.
- A review of the current deploy path, with the specific failure modes it allows today.
- A target architecture for compute, networking, and secrets, with the reasoning for each choice.
- An observability plan: which signals matter, what pages a human, and where incidents route.
- A prioritized remediation list separating what to fix now from what can wait.
- Infrastructure-as-code patterns your team can extend without me.
05Evidence
This is not theoretical
The approach above describes work I led, not a framework I read about.
Case study · CoinDCX
HSM-Backed Cold Custody Wallet Platform
Designed and delivered a cold-custody wallet platform with HSM-protected keys, multi-signature authorization, and a sub-30ms configurable policy engine. Served 100K customers and 10K daily transactions with full auditability and no per-rule code deploys.
Technical write-up
Two Servers, One Secret: Envelope Encryption Inside Nitro Enclaves with KMS
A working implementation of attestation-bound decryption: only a specific, measured enclave can read the payload.
Technical write-up
Deploy on GitHub Release with a Kubernetes Operator (Helm + KEDA)
Automating rollout from a release event, including the failure modes I hit on the way there.
Next step
Tell me how a change reaches production today.
What the deploy looks like, who gets paged, and what you are protecting. That conversation usually surfaces the real constraint faster than an architecture diagram does.