Software Engineering

Answer-First: Combining internal gRPC transport with an automated REST JSON Gateway (grpc-gateway) provides sub-millisecond HTTP/2 inter-service RPC performance while exposing standard OpenAPI/REST endpoints to web/mobile clients, guaranteed through Protocol Buffer contract linting and backward-compatible schema versioning. Parent Architecture Guide: This article is part of our pillar series on Ecommerce Architecture & Composable Migration. The sequence diagram below illustrates the end-to-end request lifecycle as an external REST/JSON HTTP client payload is transcoded by the API Gateway into high-performance gRPC Protobuf binary calls across internal microservices. ...

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 read-only Go microservices alongside legacy Magento. API Gateway feature flags route read requests to Go with automatic fallback to Magento on failure. Embedded Debezium streams MySQL binary log updates to Redis Streams with sub-2-second sync latency. ...

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 implements event-driven dual-write where microservices update PostgreSQL and publish domain events to Dapr PubSub. The sync adapter service updates legacy Magento asynchronously. Concurrent write conflicts are resolved through deterministic conflict resolution policies tailored to specific domain data types. ...

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: Phase 3 cutover executes an immediate 100% traffic shift for stable read services and a graduated ramp over 10 days for transactional services. Legacy Magento remains a hot standby for 30 days while automated ArgoCD gitops pipelines handle production deployments. ...

Answer-First: Distributed transaction consistency is achieved using a choreography-based saga paired with a PostgreSQL transactional outbox. Business mutations write to the outbox atomically. Background workers publish events to Dapr PubSub every 500ms, while idempotent consumer handlers process compensation events on failure. 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. ...

Answer-First: Architectural Decision Records (ADRs) enforce three core principles: resilience over simplicity, strict layer standardization, and explicit event-driven boundaries. Standardizing service layouts, outbox patterns, and database migrations before writing code ensures consistent microservices governance across large engineering teams. 21 services. 24 decisions. 3.5 months of deliberation captured in Architecture Decision Records. An ADR (Architecture Decision Record) is a short document that answers the question: “Why did we choose X when Y and Z were also options?” Without ADRs, architectural knowledge lives in engineers’ heads. When they leave, the knowledge leaves too — and the next team rewrites the same component in the way that was already tried and rejected. ...

← Series hub ← Prev • Next → Executive Summary & Quick Answer: Alipay’s tech stack combines SOFAStack middleware, OceanBase distributed databases, and lightweight Service Mesh sidecars to achieve high-density microservice deployments with low inter-service RPC overhead. Prerequisite: Phase 3: Operations Playbook This phase describes the core technology layers and software engineering paradigms that Alipay developed to scale its transaction processing systems. Building systems for Double 11 is not only an infrastructure scaling challenge; it is a software complexity challenge. The engineering team had to design a unified core platform capable of handling thousands of distinct business requirements (promotions, installment plans, international cards) without turning the codebase into an unmaintainable monolith. ...