From Zero to Scalable Logistics: A Real‑World Backend Architecture Evolution

Preface

Searching online for "architecture" yields countless articles, yet many still struggle to define it or design it for concrete business scenarios. Architecture can refer to a technical framework, an application system, a large‑scale distributed service, or even internal product business. The author shares personal and borrowed experiences in story form, acknowledging that the characters and events are fictional.

From Zero to One

Entrepreneur Xiao Ming launches a cross‑border e‑commerce startup. As user volume grows, logistics experience becomes a bottleneck, prompting the creation of a logistics department with three sub‑teams: BD, Operations, and Product‑Technology. The product‑technology director, Lao Wang, designs a lightweight 1.0 logistics system to keep things simple while allowing future iteration.

The 1.0 design includes a logistics order center that tracks the lifecycle of a shipment, a merchant‑side shipping platform, and a gateway for logistics providers. Teams are split into a fast‑shipping team (frontend + two backends), an order‑center team (two backends), and a gateway team (senior backend). Each team handles its own testing, with integration tests coordinated by dedicated testers.

Lao Wang enumerates technical challenges for each subsystem, such as high‑concurrency order creation, atomic updates, sharding, global ID generation, query capabilities for buyers and sellers, historical archiving, state‑machine design, messaging, distributed transactions, and secure APIs.

First Architecture Upgrade

After a new funding round, medium‑size merchants demand ERP integration. Lao Wang proposes version 1.1, but after consulting business and product owners, realizes the gateway would become a high‑coupling hub. He refactors the design, extracting a dedicated Shipping Center to serve both small merchants (via a web portal) and ERP merchants (via a specialized gateway).

The resulting 2.0 architecture separates the Shipping Center, Express Shipping Portal, and ERP Shipping Portal, reducing coupling and aligning services with business growth.

Express Expansion

With more merchants joining, the platform faces a shortage of logistics providers. To accommodate small, region‑specific carriers, Lao Wang adds a Resource Center to record each carrier’s capabilities and upgrades the Gateway to a Distribution Center that creates distribution orders for real‑world deliveries. This evolution, labeled 2.5, optimizes routing without fundamentally changing business logic.

Warehouse Is King

International logistics partners introduce warehouse‑based fulfillment. To support this, Lao Wang adds a Warehouse Center that creates warehouse orders, manages a warehouse‑order state machine, and acts as a gateway to external warehouse systems. The Resource Center now also tracks warehouse capabilities, enabling the Shipping Center to route orders to either carriers or warehouses. This new design is called version 2.8.

Small Merchants Can Use Large Warehouses

To let small merchants benefit from warehouse services, the team builds a Warehouse Shipping Portal and integrates it with the Shipping Center. The resulting 2.9 architecture adds this portal but later proves that offering warehouse fulfillment to small merchants is not cost‑effective.

Second Upgrade

A mis‑operation takes several order‑center nodes offline, causing a cascade failure that brings down the entire platform. The post‑mortem reveals the logistics order center had become a single point of failure because it handled both merchant‑side and carrier‑side responsibilities. Version 3.0 separates these concerns: an Order Fulfillment Center tracks actual fulfillment (warehouse and distribution), while the Order Scheduling Center throttles traffic to protect downstream systems.

Conclusion

Architecture evolution is driven by business but must also consider performance and stability. Good architecture is about problem decomposition and solution, while poor architecture collapses under pressure. Continuous evolution tests an architect’s skill, and mastering it separates successful systems from those that repeatedly rebuild.