Composable Commerce Migration: Magento 2 → Microservices Golang#
Is your Magento 2 store costing you $125,000–$200,000/year in Enterprise license fees? Are your engineers spending 60% of their sprint chasing PHP compatibility issues and writing hacky module overrides instead of shipping features? Are you hitting the ceiling on flash-sale traffic because you can only scale the entire monolith at once?
Welcome to the definitive playbook for Composable Commerce Migration — how to surgically disassemble a Magento 2 monolith into a production-grade microservices platform built on Go 1.25, Kratos v2, Dapr PubSub, and Rush monorepo, without losing a single order in transit.
About this Series
This content is distilled from building a real Composable Commerce Platform — 21 Go microservices + 2 frontends handling the complete commerce journey: Browse → Search → Cart → Checkout → Pay → Fulfill → Ship → Return — with zero Magento license fees and full data ownership. Every architecture decision in this series is backed by one of our 24 Architecture Decision Records (ADRs).
🎯 Migration Consulting#
Is your team planning to exit Magento or evaluating a migration to a composable commerce architecture? Need an Architecture Review of your current platform before committing to a migration strategy?
👉 Book a 1:1 Architecture Consultation with Senior Architect Lê Tuấn Anh — 17+ years building enterprise e-commerce platforms across Vietnam and SEA.
📚 Core Curriculum#
Magento 2’s EAV schema, integer primary keys, and PHP module coupling make migration uniquely treacherous. This series gives you the complete 3-phase Strangler Fig playbook with working Go code:
Part 0: Executive Summary — Why $200K/Year Is a Trap
The real cost of Magento Enterprise, and why the composable architecture pays for itself in Year 1.
Part 1: DDD Bounded Contexts — Decomposing Magento Modules
How to map Magento’s module structure to 21 bounded contexts using Domain-Driven Design — without a Big Bang rewrite.
Part 2: Rush Monorepo — Managing 21 Go Services + 2 Frontends
Why we chose Microsoft Rush over Nx/Turborepo for a mixed Go + Next.js + React monorepo, and how to set it up.
Part 3: Golang + Kratos v2 — Microservice Framework Internals
How Kratos v2 handles transport, dependency injection, and the common library pattern across 21 services.
Part 4: gRPC Internal + REST Gateway Architecture
Service-to-service communication in gRPC, REST exposure via gRPC-Gateway, and the API Gateway routing strategy.
Part 5: EAV Schema Migration — Magento’s Biggest Trap
Untangling catalog_product_entity_varchar, integer → UUID identity mapping, and the exact SQL extraction queries that work.
Part 6: Phase 1 — Strangler Fig: Read-Only Migration + CDC
Deploy read-only Go services behind an API Gateway, implement real-time CDC sync from Magento MySQL, and use feature flags to route traffic with zero risk.
Part 7: Phase 2 — Dual-Write: Dapr PubSub + Feature Flags
Enable write APIs on microservices, implement bidirectional sync via Dapr PubSub + Transactional Outbox, and resolve conflicts with timestamp-wins policy.
Part 8: Phase 3 — Full Cutover: Zero Downtime + GitOps
Gradual 25/50/75/100% traffic cutover per service, Magento hot-standby for 30-day rollback window, and ArgoCD GitOps deployment.
Part 9: Transactional Outbox + Saga Pattern Across Services
How the Checkout → Order → Payment → Warehouse saga runs with guaranteed delivery using Transactional Outbox and Dapr PubSub Dead Letter Queue.
Part 10: ADR Walkthrough — 24 Architecture Decisions Explained
Every major decision — Dapr vs Kafka, database-per-service, gRPC vs REST, monorepo vs polyrepo — with the trade-offs that led to each.
| Capability | Magento Enterprise | This Platform |
|---|
| License cost | $125,000–$200,000/year | $0 |
| VNPay / MoMo payments | Third-party plugins, unreliable | Native, circuit breaker, failover |
| Flash sale scaling | Scale entire monolith 10× | Scale only Order + Payment 10× |
| Multi-warehouse WMS | Enterprise add-on only | Built-in: bin location, batch picking |
| Event reliability | Webhooks miss, synchronous hooks | Transactional Outbox + Dapr PubSub + DLQ |
| Data ownership | Vendor-hosted | Self-hosted, full control |
🧭 Where Should You Start?#
Frequently Asked Questions (FAQ)#
Does this series assume I'm already running Magento 2?
Yes. The migration guides target Magento 2.x (Open Source or Commerce). The EAV schema, integer primary keys, and module coupling patterns are all Magento 2-specific. If you’re on Magento 1, the DDD and Golang patterns still apply but the SQL extraction queries will differ.
What Golang version and framework does the platform use?
The Composable Commerce Platform runs on Go 1.25 with Kratos v2 (go-kratos), Google’s production microservice framework used in Bilibili and other large-scale Go deployments. All 21 services share a common library (v1.10.0) that standardizes outbox, idempotency, health checks, and config management.
What is Rush and why not use a standard Go workspace or Nx?
Microsoft Rush is a polyglot monorepo manager that handles both Go services and Node.js frontends (Next.js + React) under a single repo with incremental builds, workspace policies, and changeset management. We chose Rush over Nx because of its superior handling of mixed-language repos and its first-class support for PNPM workspaces on the frontend side.
Can the migration be done without downtime?
Yes. The 3-phase Strangler Fig approach (Read-Only → Dual-Write → Cutover) is designed for zero downtime. Phase 1 routes only reads to microservices; writes still go to Magento. Phase 2 introduces dual-write with feature flags for instant rollback in under 10 seconds. Phase 3 gradually shifts traffic 25% → 50% → 75% → 100% per service with Magento on hot standby for a 30-day rollback window.
Every engineering team that’s built seriously on Magento eventually hits the same three walls: the licensing wall, the scaling wall, and the developer velocity wall. The question is whether you hit them before or after they cost you real money and real customers.
Answer-first: A Composable Commerce Platform built on 21 Go microservices, Kratos v2, and Dapr PubSub can replace Magento Enterprise — delivering the same commerce capabilities (multi-warehouse, payment saga, loyalty engine, real-time search) — at zero license cost, with the ability to scale individual services independently during peak traffic.
...
Every Magento team that decides to migrate to microservices faces the same first question: how many services?
The industry says 4–6. “Catalog service, Order service, Customer service, Inventory service, Payment service, and maybe CMS.” Every blog post, every conference talk converges on this list. It’s a reasonable starting point — and it’s wrong for serious e-commerce at scale.
The Composable Commerce Platform we’re documenting in this series has 21 microservices across 6 bounded context groups. That’s 3–4× the industry recommendation. This article explains why — with a complete Magento module → service mapping table, and the two counter-intuitive domain splits that Magento engineers almost always get wrong.
...
When you have 21 Go microservices and 2 frontend applications, the first infrastructure question isn’t Kubernetes or CI/CD — it’s how do you manage the code itself?
Two options fail immediately: polyrepo (21+ separate Git repos, impossible to maintain consistent versions) and a naive monorepo (everything dumped in one folder, phantom dependencies everywhere). You need a proper monorepo manager.
Scope note: Rush manages the frontend layer (Next.js, TypeScript packages). Go microservices are managed independently via go.mod and Go workspaces. The structure below reflects the platform’s recommended approach — verify rush.json specifics against your team’s actual repository before adopting wholesale.
...
For engineers coming from Magento PHP, the shift to Go microservices isn’t just a language change — it’s a fundamentally different way of organizing code. Magento has controllers, models, blocks, helpers, and plugins. Go with Kratos v2 has exactly five layers, each with a precisely defined responsibility.
Answer-first: A production Go microservice on this platform follows the Kratos v2 directory convention (api/ → cmd/ → internal/biz/ → internal/data/ → internal/server/), uses Google Wire for compile-time dependency injection, exposes both HTTP and gRPC simultaneously on different ports (8xxx/9xxx), and imports a shared common library at v1.9.5 that provides outbox, caching, worker, metrics, and logging — standardized across all 21 services.
...
Every public-facing API in the Composable Commerce Platform starts as a .proto file. The code — Go gRPC handlers, TypeScript SDK, HTTP routes, request validation, error codes — is generated from that contract. This article documents the conventions that make that system work.
Answer-first: Internal services communicate via gRPC (type-safe, binary, ~7× faster than JSON over REST). External clients (browser, mobile app) use REST via the Gateway Service (port 8000). The proto file is the single source of truth for the API contract — and three proto conventions require special attention for engineers coming from Magento: the Money type (never use float for prices), cursor-based pagination (never use offset), and proto-level field validation (validation declared in the contract, not in business logic).
...
The EAV schema is why most Magento migrations fail.
It looks manageable from the outside: products stored across catalog_product_entity, catalog_product_entity_varchar, catalog_product_entity_int, catalog_product_entity_decimal, catalog_product_entity_datetime, and catalog_product_entity_text. Six tables, straightforward ETL job, done in a weekend.
Then you discover that attribute_id = 75 means “product name” in your Magento instance and “color” in your staging instance. Every attribute ID is generated at install time and differs between environments. Any ETL script that hardcodes attribute IDs will produce corrupted data in production.
...
Phase 1 is the safest phase of the migration — by design. No write operation touches the new microservices. Magento remains the source of truth for all data modifications. The only thing Phase 1 does is prove that your microservices can serve reads faster and more reliably than Magento.
Answer-first: Phase 1 deploys Go microservices in read-only mode, routes GET requests to them via the API Gateway’s per-domain feature flags (with automatic fallback to Magento if the service is unhealthy), and uses Debezium — running in embedded engine mode without a standalone Kafka cluster — to stream Magento MySQL changes to the microservices via Dapr PubSub on Redis Streams. Writes continue to go to Magento. Data latency target: < 2 seconds.
...
In Phase 1, both systems existed but only one wrote data: Magento. In Phase 2, both systems write data simultaneously. This is the most technically complex phase — and the one where most migrations introduce data corruption if they don’t have an explicit conflict resolution strategy.
Answer-first: Phase 2 uses event-driven dual-write — not raw database dual-write. Microservices write to their PostgreSQL first, then publish a domain event to Dapr PubSub. The magento-sync-adapter service subscribes to those events and writes back to Magento. Conflicts (both systems update the same record concurrently) are resolved by a 5-policy matrix that differs by data type: timestamp-based for customer profiles, microservices-wins for order status and stock levels, and summation reconciliation for coupon usage counts.
...
Phase 3 is the final act: 100% of traffic moves to microservices, Magento becomes a passive archive, and the platform runs entirely on Go microservices via GitOps. No PHP in the critical path. No Magento license renewal needed.
Answer-first: Customer and Catalog services cut over at 100% immediately (they’ve been stable through all of Phase 2). Order Service uses a graduated 25%→50%→75%→100% ramp over 10 days, with a monitoring hold at each step. Magento stays alive as a hot standby for 30 days — an archive-service syncs microservice data to Magento hourly (one-way, for regulatory compliance). All deployments use ArgoCD + Kustomize; a git commit triggers a production deployment within minutes.
...
When a customer places an order on the Composable Commerce Platform, seven events need to happen in sequence across four independent services: Order created → Payment authorized → Stock reserved → Fulfillment triggered → Notification sent → Loyalty points awarded → Shipping label generated. Any of these can fail. The network can fail. The database can fail. A third-party payment gateway can time out.
Without a reliability mechanism, a 2% failure rate on any step means 2% of all orders are stuck in an inconsistent state, requiring manual intervention.
...