Cloud / Distributed systems
Monolith to Microservices on EKS: Ownership, Migration and Rollback
A real client engagement. The engineering and the results are described below.
A commerce platform we worked with can add features only when several teams coordinate one large release. Its EKS migration story asks which service boundary can reduce that coordination burden without assuming new demand or borrowing results from the separate owner-reported project.
Request a time through the inquiry form. A meeting is confirmed separately by email.
The business problem behind the technology
Can one service extraction make delivery meaningfully easier?
24 staff-hours of coordination and recovery preparation per release was slowing useful delivery. Splitting the application without data ownership would add network failure modes without removing that burden.
Read the client engagement ↓Client engagement / Delivered results
The first service boundary had to earn its operating cost
A commerce company we worked with makes eight coordinated releases each month. This engagement is separate from the linked owner-reported EKS account and its reported daily-user endpoints.
The constraint
24 staff-hours of coordination and recovery preparation per release was slowing useful delivery. Splitting the application without data ownership would add network failure modes without removing that burden.
The engineering decision
The team extracts one bounded capability behind reversible routing, defines its data contract and keeps recovery compatible during the transition. Comparable release coordination fell from 24 to ten staff-hours after the boundary was proven.
The delivered outcome
The effort ledger fell from 192 to 80 hours a month, freeing engineering capacity for the client.
| Measure / unit | Before | After | Difference |
|---|---|---|---|
| Release coordination and recovery-preparation effort hours/month | 192 | 80 | 112 |
Release coordination and recovery-preparation effort. Eight × 24 versus eight × ten staff-hours. Parallel contributors are counted as effort, not calendar time.
The conditions behind the results
- Release scope, review quality and recovery obligations remain comparable.
- The eight-release volume and effort values are this engagement’s, separate from the owner-reported project.
- Additional platform operations, migration effort and cloud charges are excluded and can offset the benefit.
What this does not prove. The freed engineering effort is this engagement’s operating result, separate from the owner-reported growth story.
The linked client project account describes the same engagement from the project side.
Evidence to collect for your own decision
- Map the capability’s callers, data owner and deployable boundary.
- Test routing rollback, duplicate events and compatibility during data transition.
- Measure coordination effort and operating load before extracting another service.
Key decisions
Daily users are not concurrent requests, desired Pods are not Ready capacity, and Kubernetes does not manufacture revenue. A credible scaling story connects demand, service boundaries, data integrity and operating economics.
- Map the capability’s callers, data owner and deployable boundary.
- Test routing rollback, duplicate events and compatibility during data transition.
- Freed engineering effort is not payroll savings or evidence that Kubernetes caused audience or revenue growth.
Follow the decision
Select a step to follow its reasoning, then continue into the technical chapters.
Problem → boundary → decision → evidence
Understand what the reported audience metric can and cannot establish.
Read every component and connection
- Translate demand · Problem
- Understand what the reported audience metric can and cannot establish.
- Move one boundary · Boundary
- Separate ownership and data changes with a way back.
- Control load · Decision
- Keep autoscaling, queues and retries from amplifying failure.
- Translate demand → Move one boundary: identify the constraint
- Move one boundary → Control load: choose a bounded change
- Control load → Retain proof: check the outcome
A conceptual decision map for this article, not a measured timeline, physical topology or a depiction of a specific client system.
Hover, focus or tap a component to inspect it. Motion adapts automatically to connection, device and accessibility signals; the component key remains readable without JavaScript.
Translate the audience metric before sizing the platform
The client’s commerce team looks for a capability whose ownership change can actually reduce coordination.
Preserve the actual definition and counting window behind daily users. A visitor, signed-in account, device and session are not interchangeable. The reported endpoints imply 1,000× daily-user growth; they do not specify requests per second, concurrency, database writes, bandwidth, paying customers or a revenue multiplier.
For transparent capacity planning, take thirty application requests per user-day and an eight-times-average busy interval. Twenty million daily users then imply about 6,944 average requests/second and 55,556 at the peak. At 250 requests/second per Ready API replica, the arithmetic floor is 223 replicas before headroom. These rates are planning inputs, not benchmark results.
Measure the real request mix, cache-hit ratio, payloads, fan-out, retry amplification and downstream quotas. Load-test representative failure and recovery conditions, not only a warm happy path. A faster web tier can make an under-provisioned database fail more efficiently.
Reported scale: 20,000 → 20,000,000 daily users
Planning inputs: 30 requests/user-day; peak = 8 × average
Average = 20,000,000 × 30 / 86,400 ≈ 6,944 requests/s
Peak ≈ 55,556 requests/s
At 250 requests/s per Ready replica:
ceil(55,556 / 250) = 223 Ready replicas, before headroom
This is not node count, concurrency or measured capacity.Migrate one ownership boundary at a time
Microservices architecture becomes practical one ownership boundary at a time. The migration needs a reversible unit of change.
Use an incremental routing boundary around the existing application. Extract a service where independent change or scaling pays for its operational cost, then move a bounded request cohort. Establish a rollback-compatible API and compare outcomes before expanding. A collection of network calls to the same shared tables is a distributed monolith, not a completed microservices migration.
Give each service an accountable owner, interface, data contract and failure policy. Evolve schemas with expand-and-contract changes so old and new versions can coexist. For side-effecting workflows, use idempotency keys and an outbox or another deliberately chosen consistency mechanism; do not assume a retry is harmless.
Keep payment and authorization paths fail-closed. Noncritical recommendations or optional enrichment can degrade independently when their dependencies are unavailable. Document which stale reads are acceptable and where a user must receive a clear failure instead of a fabricated success.
Separate workload scaling from EKS node provisioning
The workload asks for more replicas while the node pool has its own lifecycle. Treating those as one event hides the delay.
HPA changes a workload’s desired replicas using the configured metric and policy. Resource-utilization targets depend on requests; a missing request is not zero utilization. Stabilization, rate limits and startup effects matter. Queue-driven workers need signals such as age and backlog that describe their actual deadline rather than an arbitrary CPU target.
The scheduler still needs resources, placement and compatible storage. EKS node capacity can be supplied through an explicitly owned mechanism such as Cluster Autoscaler, Karpenter or EKS Auto Mode; do not imply that all three should compete over the same fleet. Capacity launch time is not an application-readiness guarantee.
Use availability-zone placement, topology-aware replicas, meaningful readiness checks and a critical capacity floor. PDBs constrain supported voluntary disruptions such as drains; they do not directly veto HPA or Deployment replica reduction. Node consolidation and workload scale-down have different owners and failure modes.
Keep demand spikes from becoming retry storms
The proposed service has to retain compatible data and recovery before its effort model deserves confidence.
Cache only where freshness, authorization and invalidation rules permit. Put bounded queues between asynchronous stages and expose age, completion and dead-letter outcomes. Limit concurrency at the service and dependency boundaries, and budget retries across the full request path instead of independently multiplying attempts at every hop.
Partition and index the data path based on observed access patterns. Use replica reads only where their consistency is acceptable. Test hot tenants, expensive queries and recovery after a cache loss. Moving containers to EKS does not remove database connection limits, external-provider quotas or cross-zone transfer charges.
Under overload, reject or defer work deliberately before expensive resources collapse. Preserve the critical customer transaction and make degradation observable. Revenue protection comes from completed, correct customer outcomes—not a high count of accepted HTTP connections.
Make independent deployment safe enough to be ordinary
Independent services are useful only when independent releases are safe. The story moves from topology to ordinary deployment behavior.
Build one identifiable release and promote the same image digest through checks and environments. Keep environment configuration versioned separately. Contract checks, migration compatibility and synthetic business transactions should inform release approval; a green unit suite is not proof that a new schema can roll back.
Progress through bounded traffic cohorts and pause on release-correlated errors, saturation or business failures. A nominal one-percent canary is a fraction of routed traffic, not necessarily a representative one percent of users. Choose minimum samples and evaluation windows from the signal you need rather than blindly waiting a fixed day.
Measure lead time and failed-change outcomes per service. Counting forty service deployments against one old monolith release can exaggerate the apparent improvement. At a fixed release workload, reductions in manual effort are a legitimate capacity model; actual higher frequency must still earn its operating cost.
Treat revenue as a measured consequence, not a Kubernetes feature
Commercial growth belongs in the account, but not inside a Kubernetes feature claim. The evidence has to distinguish correlation from a measured consequence.
The linked case uses two separate commercial sensitivities. A direct-sales availability example uses a 0.2% purchase rate, $40 of revenue per completed purchase and uniform affected demand; moving an availability objective from 99.5% to 99.95% corresponds to $216K/month of conditional revenue protection at the reported final audience. These are conditional exposure figures used for planning.
A separate successful product experiment lifting conversion from 0.20% to 0.21% would imply $2.4M/month of additional gross revenue under the same audience and price inputs. Faster deployment can enable that experiment; it cannot guarantee the conversion effect. Validate the effect through an appropriate experiment and account for returns, fulfillment, customer acquisition and margins.
Do not add the conversion, availability and infrastructure examples into one unsupported ROI total. The normalized $1.2M to $780K monthly infrastructure comparison uses the same final traffic, not a linear extrapolation of a small-business bill. Realized revenue, contribution margin, cash savings and staff capacity remain different quantities.
Keep a verification record that survives the growth story
The owner-reported audience endpoints remain separate; the client’s team closed its decision on measured coordination and operating work.
Retain analytics definitions, workload profiles, service-level indicators, release and incident histories, cost allocation and finance-reviewed revenue measures. Correlate deployment identity through logs, metrics and traces. Missing telemetry is a blind spot, not evidence of reliability.
Exercise an availability-zone loss, a dependency slowdown, a bad deployment, queue replay and database restoration. Verify both customer-visible recovery and data correctness. A rollback command succeeding is not the same as an order, account update or scheduled job completing correctly.
Credit the platform for the constraints it removed and the operating risks it controlled. Product demand, marketing, pricing and sales also shape audience and revenue. The engineering contribution can be substantial without claiming that an orchestration platform alone caused the entire business to grow.
Questions behind the decision
When should a monolith move to microservices?
When a concrete scaling, ownership or delivery constraint justifies the additional distributed-system cost. A modular monolith may be the better answer when the team cannot independently operate, observe and recover the proposed services.
How does a strangler migration reduce cutover risk?
It routes a bounded capability to a replacement while retaining the rest of the original system. The reversibility still depends on data ownership and compatibility; switching traffic back does not undo incompatible data changes.