Answer-first: How we escaped Magento's licensing and scaling walls by migrating to a Composable Commerce Platform built on 21 Go microservices, Dapr PubSub, and a 3-phase Strangler Fig strategy without dropping a single order.
At exactly midnight during a major campaign, a monolithic Magento server can quickly become your single point of failure. Every engineering team that builds seriously on Magento eventually hits the same walls: the licensing wall ($100k-$200k/year for Enterprise), the scaling wall (scaling the entire massive codebase just to handle a traffic spike on the checkout page), and the developer velocity wall.
When we decided to migrate away from Magento, the standard industry advice was to split the monolith into "4 to 6 microservices". We ignored that advice. For serious e-commerce at scale, that approach inevitably leads to a distributed monolith — where services are deployed separately but remain tightly coupled through HTTP chains or shared database tables.
Instead, we built a Composable Commerce Platform using 21 Go microservices, Google's Kratos v2 framework, and Dapr PubSub. Here is the blueprint of how we structured it, and how we migrated with zero downtime.
For the complete architecture deep-dive across all domains, see the Composable Commerce Migration Series.
The 21-Service Blueprint: Domain-Driven Design in Practice
Before writing a single line of Go code, we established boundaries using Domain-Driven Design (DDD). Every domain owns its own PostgreSQL database. There are absolutely no cross-domain queries.
Here is the breakdown of our 6 core domains:
- Commerce Flow (Checkout, Order, Payment): The highly critical money path, orchestrated using Saga patterns.
- Product & Content (Catalog, Pricing, Promotion, Search): Read-heavy, heavily cached, requiring sub-50ms latency.
- Logistics (Warehouse, Fulfillment, Shipping): Integration with the physical world and 3PLs.
- Post-Purchase (Returns, Loyalty): Customer retention and post-sale state machines.
- Identity & Access (Auth, User, Customer): Strict separation between internal staff (RBAC) and external customer PII.
- Platform Operations (Gateway, Analytics, Notification): Shared infrastructure utilities.
Here is how traffic flows through the ecosystem. (For the full traffic anatomy and Elasticsearch CQRS implementation, see the Architecture Blueprint).
The 3 Rules of Decoupling: Avoiding the Distributed Monolith
The most common failure mode when migrating from a monolith is building a system where a single failure in a non-critical service cascades and takes down the checkout flow. We avoided this with three hard rules:
- No cross-domain database queries. If the Order service needs product data, it cannot query the Catalog database. It must either hold a denormalized copy (via CQRS) or call the Catalog service's gRPC API. This ensures schema changes in one domain never break another.
-
No synchronous calls in the async event path. Once an event (e.g.,
order.paid) enters the Dapr PubSub mesh, it is processed independently. Downstream services like Fulfillment or Loyalty react to the event, but they never synchronously call back into the producer. If the Loyalty service is down, the order still succeeds. - No shared deployment pipelines. Every service lives in a Rush monorepo but has its own ArgoCD Application and container registry path. A bug or a blocked deployment in the Notification service cannot block a hotfix for the Checkout service.
The Zero-Downtime Migration Strategy: The 3-Phase Strangler Fig
Magento's EAV (Entity-Attribute-Value) schema is a trap. You cannot just run an ETL job over the weekend and cut over traffic. We used a strict 3-Phase Strangler Fig approach to ensure zero dropped orders:
- Phase 1 (Read-Only via CDC): We deployed the Go microservices in read-only mode behind our API Gateway. We used Debezium to stream Magento MySQL changes to our Go services via Dapr. Writes still went to Magento.
- Phase 2 (Dual-Write & Conflict Resolution): Microservices started accepting writes, persisting to their own Postgres DBs, and publishing domain events. A sync-adapter service listened to these events and wrote back to Magento. Conflicts were resolved by explicit policies (e.g., timestamp-wins).
- Phase 3 (Full Cutover via GitOps): Using ArgoCD, we gradually shifted traffic per service: 25% → 50% → 75% → 100%. Magento was kept on "hot standby" for a 30-day rollback window.
Takeaways:
- Establish boundaries before writing code. Extract services based on business domains (DDD) and data ownership, not UI pages.
- Enforce the DB-per-service rule strictly.
- CDC is your best friend during migration.
- Do not do a "big bang" release.
Why Go (Golang) instead of Node.js or Java for microservices?
Go provides the perfect balance for e-commerce microservices: it compiles to a single static binary (fast startup for scaling), uses very little memory compared to JVM languages, and has excellent concurrency primitives (goroutines) for handling high-throughput API gateways and event consumers.
How do you handle distributed transactions across 21 services?
We don't do distributed locks or 2PC (Two-Phase Commit). We use the Saga Pattern orchestrated by the Checkout service, leveraging Dapr PubSub. If a step fails, the orchestrator fires compensating events to roll back previous steps.
Does the API Gateway become a new monolith?
No. The gateway only handles Auth, Rate Limiting, and basic routing. We strictly forbid placing business logic in the API Gateway. It acts purely as a traffic shield and BFF (Backend-For-Frontend).
For the full engineering blueprint — including the exact EAV extraction SQL and our Dapr Saga implementation — read the complete Composable Commerce Migration Series.
FAQ
Q: How do you migrate from Magento to microservices without downtime?
A: The safest path is the 3-Phase Strangler Fig pattern: Phase 1 deploys new microservices alongside Magento in read-only mode — reads hit the new services, writes still go to Magento, with Debezium CDC syncing Magento's MySQL binlog to the new services in real time. Phase 2 gradually migrates write APIs (starting with lower-risk domains like Customer, then Catalog, then Order), using bidirectional Dapr Pub/Sub sync to keep Magento's legacy Fulfillment module in sync. Phase 3 cuts all traffic to microservices but keeps Magento as a hot standby with reverse sync for 30 days before termination. Each phase includes a feature flag for sub-10-second rollback.
Q: What is Debezium and why is it used in Magento migration?
A: Debezium is a Change Data Capture (CDC) tool that streams MySQL binary log (binlog) events to a message broker in real time. In a Magento migration, it solves the data consistency problem during the transition period: instead of batch ETL jobs that create race conditions, Debezium captures every INSERT, UPDATE, and DELETE from Magento's MySQL database the moment it happens and publishes it to Dapr Pub/Sub. The new microservices subscribe to these events and keep their own databases synchronized. This creates a continuous, event-driven data bridge between the legacy system and the new architecture with no polling loops or cron jobs.
Q: How do you handle Magento's integer IDs vs UUIDs in microservices migration?
A: Magento uses sequential integer entity_id values as primary keys across all tables. Modern distributed microservices use UUIDs to avoid ID collisions across independent databases and services. The solution is a magento_id_map cross-reference table maintained during the migration period: every Magento integer ID is mapped to a generated UUID before insertion into the new service's database. All new writes from microservices generate UUIDs directly. The Legacy Sync Worker that writes microservice events back into Magento performs the reverse lookup — UUID to integer — when creating records in Magento's EAV schema. This mapping table is the source of truth during dual-write and is retired after the hot standby period ends.
Q: What is bidirectional sync in a microservices migration?
A: Bidirectional sync is the dual-write pattern used during Phase 2 of the migration when both Magento and the new microservices are simultaneously handling writes. When a microservice (e.g., Order Service) processes a transaction, it writes an order.created event to its outbox table in the same database transaction. A Legacy Sync Worker consumes this event from the Dapr Event Mesh and writes it backward into Magento's database, translating modern payloads back into Magento's EAV schema format. Conflict resolution uses timestamp precedence — the newest write wins. This bidirectional sync allows legacy modules still running inside Magento (e.g., Fulfillment) to remain functional while the migration completes.
Hi, I'm Lê Tuấn Anh (vesviet) 👋
I am a Senior Go Backend Architect & Distributed Systems Engineer with 17+ years of experience building high-traffic platforms (25M+ requests/month).
If you enjoyed this deep-dive, let's connect on LinkedIn or explore my consulting services at tanhdev.com/hire.
Top comments (0)