DOM Technical Architecture

1. Overview

Distributed Order Management is the orchestration layer that picks the optimal fulfillment point for every order in a multi-location environment. The system handles the process from order intake to location selection to work-order generation.

DOM is a module of the Omniens platform and integrates with the following layers:

• OMS (Order Management): Order intake, validation, and state management
• Inventory Service: Real-time stock visibility
• Carrier Service: Carrier integrations and label generation
• WMS Connectors: Location-based work-order communication

2. Sourcing Engine — Location Selection Process

The sourcing engine at the heart of DOM evaluates rules on every incoming order and selects the optimal location. The process is designed to be deterministic and auditable.

2.1 Flow

1. List candidate locations: All active fulfillment points (warehouses, stores, 3PLs, dropship partners) are loaded as a candidate list.
2. Stock pre-filter: Locations without sufficient stock for the ordered SKUs are eliminated. Reservation states are taken into account.
3. Rule engine evaluation: Each candidate location is passed through the defined rule set (hard constraints, customer segment, category-based restrictions).
4. Scoring: Remaining candidates are ranked by weighted scoring.
5. Capacity check: Verify the highest-scoring location hasn't exceeded its daily SFS capacity limit.
6. Assign and commit: Location is selected, stock is reserved, work order is dispatched to WMS.

2.2 Scoring Factors

Location scoring uses the following weighted dimensions. Weights are configurable per organization:

3. Rules Engine

The rules engine is configurable from the management panel. Two rule types are supported:

3.1 Hard Constraints

If violated, the location is removed from the candidate list entirely. Examples:

• "Store stock only for customers of that store"
• "Items requiring cold chain only from certified warehouses"
• "Items over 5 kg can't ship from retail stores"
• "International orders only from export-ready warehouses"

3.2 Soft Constraints

If violated, a penalty score is applied, but the location isn't eliminated. Examples:

• "Prefer the central warehouse last when possible"
• "Use store stock primarily for customers in that city"
• "Prioritize 3PL partners on weekends"

3.3 Rule Configuration

Rules are defined as formulas in the management panel. A sample configuration JSON:

// Cold-chain rule
{
  "name": "cold-chain-only",
  "type": "hard",
  "applies_to": { "category": "frozen" },
  "requires": { "location_capability": "cold-chain" },
  "priority": 100
}

4. Performance Characteristics

4.1 Routing Decision Latency

4.2 Throughput

A single DOM cluster can process 2,000+ routing decisions per second. Horizontal scaling raises this ceiling. The cluster is configured to scale out automatically for peak periods like 11.11 and Black Friday.

4.3 High Availability

• Multi-AZ deployment, automatic failover
• Stateless service design; unaffected by any node restart
• SLA: 99.95% (~4.4 hours of tolerated downtime per year)
• Circuit breaker: when WMS or carrier service slows down, DOM doesn't stop responding — it routes to a fallback location

5. Integration Points

5.1 Order Intake

Orders can reach DOM via three paths:

• Order Management System: Native integration — event-based, sub-100ms communication
• REST API: POST /api/v1/orders from third-party OMSs
• Webhook ingestion: Order webhooks from e-commerce platforms

5.2 WMS Output

After a location is assigned, DOM sends a work order to the WMS. Standard formats are supported:

• EDI (X12 940/945, EDIFACT ORDERS/DESADV)
• JSON (Omniens-WMS standard)
• XML (custom customer formats)
• SAP IDoc (DELVRY03, DELVRY07)

5.3 Inventory Sync

After every assignment, DOM reserves the SKU stock at the relevant location. The reservation TTL is configurable (default 30 minutes). If a "pick failed" signal arrives from the WMS within that window, automatic re-sourcing triggers.

6. Failure Scenarios and Re-sourcing

In real operations, problems can occur after a location is selected: store staff can't find the item, a stock error is detected, the carrier doesn't arrive. DOM handles these scenarios with automatic re-sourcing:

1. The WMS or store app sends a "pick failed" event
2. DOM selects the next-best location from the original candidate list
3. A new work order is dispatched to the new location
4. The customer's order continues uninterrupted; the ETA updates automatically

7. Observability and Audit

Every routing decision is logged with its rationale. The GET /api/v1/orders/{id}/sourcing-trace endpoint shows why an order was assigned to that location. It includes:

• Candidate location list (before pre-filtering)
• Scoring detail per candidate (factor-level)
• Applied rules and their results
• Decision time (ms)
• Re-sourcing history (if any)

8. Security

• Authentication: OAuth 2.0 + API Key (mTLS optional)
• Authorization: Location-based access control (e.g., a store manager only sees their own store's orders)
• Encryption: TLS 1.3 in transit, AES-256 at rest
• Audit log: All sourcing decisions and rule changes are written to an immutable log
• Compliance: ISO 27001-certified infrastructure, KVKK and GDPR compliant

Next Steps

Request a demo to discuss how DOM can be tailored to your operation. In the first call we listen to your existing infrastructure and assess fit.