How a Platform‑Based Architecture Turns Logistics Fulfillment from Silos to Scalable Services

Background and Problem

Rapid expansion of logistics services created many business modes. Each new mode was built by copying an entire system, resulting in a “chimney” (silo) architecture. Consequences were low feature reuse, difficult cross‑mode coordination, and rising change cost; delivering a new mode often took >20 days.

Platform‑Level Goals

Provide an evolution framework that maps a business problem to a reusable technical implementation for complex fulfillment/orchestration systems.

Define core capabilities that can be migrated directly: split, route, orchestrate, compensate, govern.

Control high‑frequency change risk through plug‑in isolation, state‑machine orchestration, and a release‑governance loop.

Overall Architecture

The root cause is the absence of a unified model and clear boundaries. The solution is a platform that abstracts multiple businesses onto shared layers, turning “one business‑one system” into “many businesses on one platform”.

1. Platform Capabilities

The platform must handle the full link chain from order to completion.

2. Architecture Upgrade Principles

Ability atomization : split, route, orchestrate, compensate become independent abilities exposed via standard interfaces, allowing business layers to compose them as needed.

Plug‑in extensibility : new transport capacities are added as plug‑ins without touching the main flow.

Visual construction : configuration replaces hard‑coding; policies can be changed at runtime without service restarts.

3. System Architecture Layers

Upward adaptation : accommodate diverse business entry requirements.

Downward shielding : hide protocol and capability differences of various transport providers.

Inward consolidation : embed core transaction and generic fulfillment capabilities.

Detailed Design Methodology

Strategic design : unify business language, identify domain boundaries, and define platform responsibilities and component cooperation.

Tactical design : translate strategic abstractions into configurable, composable models, specifying decision logic and model interactions.

Stability design : use state orchestration, separate configuration from execution, and enforce release governance to ensure safe changes.

Code architecture : implement the designs as plug‑in‑friendly contracts and integration mechanisms.

3.1 Domain Model Design

The fulfillment process is abstracted into five core entities:

Customer Order : business entry carrying the original transport request.

Fulfillment Plan : orchestration unit describing split strategy and execution path.

Fulfillment Segment : independent transport task.

Capacity Provider and Capacity Plugin : hide downstream transport protocol differences.

Two decision rules drive the process:

Split Policy : decides how an order is divided.

Route Policy : selects the appropriate capacity.

3.2 Split‑Strategy Design

Splitting is a composable, recomputable, governed strategy system.

Policy identification : recognize business scenarios and evaluate multi‑dimensional rules.

Plan orchestration : generate the full order plan, create segments, and establish dependencies.

Exception recomputation : on partial failure, only the affected segments are recomputed, avoiding a full‑order re‑run.

Example hybrid split strategy (simplified pseudo‑code):

// 1) Initialize the overall fulfillment plan
Plan plan = planFactory.newPlan(order);
// 2) First‑level split by stages (e.g., pickup → trunk → last‑mile)
List<Segment> stageSegments = splitByStages(order, policy.stages());
// 3) Second‑level split within each stage by attribute rules
for (Segment stage : stageSegments) {
    // Example: further split by service level, region type
    List<Segment> attrSegments = splitByAttributes(stage, policy.attributeRules());
    // If no attribute rule matches, keep the original stage segment
    plan.addAll(attrSegments.isEmpty() ? List.of(stage) : attrSegments);
}
// 4) Build inter‑segment dependencies (sequential or parallel) based on fallback mode
plan.buildDependencies(policy.fallbackMode());
// 5) Return the executable fulfillment plan (segments + dependencies)

3.3 Core Process Design

Business Main Flow

Process definition : receive order, snapshot requirements, split order, and select primary/backup capacities for each segment.

Segment execution : dispatch tasks to external capacities and standardize execution states.

Status consolidation : aggregate segment progress into overall order status; retry, re‑assign, or terminate abnormal segments.

Configuration Management Flow

Separate human‑maintained saved configurations from system‑generated runtime snapshots.

People edit saved configurations.

The system compiles them into runtime snapshots.

Release steps include conflict detection and integrity checks.

Runtime snapshots are versioned for rollback and audit.

State Orchestration Flow

The state machine focuses on failure handling and aggregation rather than sheer state count.

Prioritize local compensation for failures instead of rolling back the entire order.

Parent order status is derived from child segment aggregation, not overwritten by a single event.

3.4 Plug‑in Capacity Design

Plug‑in isolation enables new capacities without changing core logic.

Unified contract : define a standard SPI with methods for capability checking, quoting, task creation, cancellation, status query, and callback handling.

Plug‑in governance : a registry manages plug‑in versions, health, gray‑release, and enable/disable state.

Boundary isolation : each plug‑in handles protocol conversion and state normalization; adding or replacing a capacity only touches the plug‑in layer.

public interface CapacityPlugin {
    // Check if a capacity supports the current fulfillment request
    CapabilityResult capability(CapabilityRequest request);
    // Get price or cost estimate for routing scoring
    QuoteResult quote(QuoteRequest request);
    // Create execution task in downstream capacity system
    CreateTaskResult createTask(CreateTaskRequest request);
    // Cancel an existing task (timeout, reassignment, user cancel)
    CancelTaskResult cancelTask(CancelTaskRequest request);
    // Query latest task status (for missing callbacks or compensation)
    QueryStatusResult queryStatus(QueryStatusRequest request);
    // Handle asynchronous callback and return ACK (idempotent)
    CallbackAck handleCallback(ProviderCallback callback);
}

Scenario Validation and Quantitative Impact

Three typical scenarios demonstrate universality:

Cross‑city urgent delivery – validates sequential split + time‑sensitive routing.

Cross‑city transport – validates hybrid split + cost‑balanced routing.

Cold‑chain delivery – validates attribute‑based split + compliance routing.

Key metrics before vs. after the platform transformation:

New scenario onboarding time reduced from 30‑40 person‑days to 10‑20 person‑days (≈ 50 % decrease).

Core‑process changes for adding a new capacity dropped from 5‑8 points to 0‑1 point (≈ 80 % reduction).

Average MTTR for abnormal links fell from 30‑45 minutes to 10‑15 minutes (≈ 65 % reduction).

Routing hit explainability improved from < 60 % to > 90 % (≈ 30 % increase).

Future Roadmap

Intelligent strategy recommendation : use historical data to automatically learn optimal split and routing strategies, lowering manual configuration effort.

Finer‑grained resource scheduling : support dynamic dispatch based on vehicle type, driver rating, real‑time location, etc.

Cross‑business capability reuse : expose platform abilities as plug‑in micro‑services for rapid adoption by other business lines.

Conclusion

Moving from a chimney architecture to a platform‑centric design reshapes both technology and development collaboration, delivering a sustainable, stable, and explainable solution for complex, evolving fulfillment scenarios through unified abstraction, configuration‑driven policies, plug‑in integration, and state orchestration.