Maersk · Adidas — Warehouse Automation Platform

Problem

Maersk — operating the Adidas DC — needed a single, multi-tenant automation platform that could orchestrate heterogeneous subsystems (conveyors, AMRs, robotic arms, GTP stations, packing lines) behind a unified API and SSO. The existing stack was partly monolithic, hard to deploy per-site, and lacked cross-service observability for irregular events that blocked throughput SLAs.

My Contribution

• Architected and shipped features across Adidas WES, Auction, Decanting, Packing, Returns, Robotic-Arm, BoxIt, Quadron, Multipro, SSO and Outbound services — owning end-to-end feature flow from design to production.
• Decomposed monolithic logic into 12+ loosely coupled Spring Boot microservices, dropping API p95 latency from 800ms → 600ms.
• Designed an event-driven observability layer on RabbitMQ + MongoDB that captures irregular events (stuck totes, handoff failures, hardware timeouts) across services for RCA and SLA tracking.
• Standardised Helm-based deployments across environments (prod/UAT/SIT/BV) — aligned the Adidas repo to the UPS-pattern to unify CI/CD for all client sites.
• Collaborated in Scrum with QA, DevOps and Product; delivered features under live production constraints with zero data loss.

Tech Stack

• Java 17
• Spring Boot
• Spring JPA
• REST
• RabbitMQ
• MongoDB
• MySQL
• MSSQL
• Docker
• Kubernetes
• Helm
• Jenkins
• Grafana
• Jaeger
• Nexus

High-Level Design (HLD)

flowchart LR
  UI["Adidas Frontend (React)"] --> GW["API Gateway / SSO"]
  GW --> WES["WES
(Warehouse Execution)"]
  WES --> AUC["Auction
Service"]
  WES --> DEC["Decanting"]
  WES --> PCK["Packing"]
  WES --> RET["Returns"]
  WES --> RA["Robotic Arm"]
  WES --> BOX["BoxIt
(Location Strategy)"]
  WES --> MPR["Multipro"]
  WES --> QDR["Quadron"]
  WES --> OUT["Outbound"]
  WES --> VEL["Veloce"]

  subgraph MB["Message Bus"]
    RMQ[(RabbitMQ)]
  end

  AUC --- RMQ
  DEC --- RMQ
  PCK --- RMQ
  RET --- RMQ
  RA --- RMQ
  BOX --- RMQ
  MPR --- RMQ
  QDR --- RMQ
  OUT --- RMQ

  RMQ --> EVT["Event Store
(MongoDB)"]
  WES --> DB[(MySQL / MSSQL)]
  EVT --> OBS["Grafana + Jaeger
Dashboards"]
                

Low-Level Design — Order Fulfilment Flow

sequenceDiagram
  autonumber
  participant U as Operator (UI)
  participant G as SSO + Gateway
  participant W as WES
  participant A as Auction
  participant B as BoxIt
  participant R as Robotic Arm
  participant P as Packing
  participant Q as RabbitMQ
  participant M as MongoDB Event Store

  U->>G: POST /orders (JWT)
  G->>W: createOrder()
  W->>A: allocate(order)
  A-->>W: allocation plan
  W->>Q: publish order.allocated
  Q->>B: consume → pick slot
  B->>R: trigger induction
  R-->>Q: publish arm.completed
  Q->>P: consume → pack
  P-->>Q: publish pack.completed
  Q->>M: persist lifecycle events
  W-->>U: order status (WS / poll)
                

Impact

• 99.8% uptime across production environments.
• Backend performance +25%; API latency 800ms → 600ms.
• Real-time pipeline processing 10,000+ events/min with zero data loss.
• LLM-backed inventory agent resolving 95%+ of operator queries, cutting support tickets 40%.
• Grafana dashboard migration automated — 8 hrs → 20 min across 3 network environments, 50+ dashboards.

Key Learnings

• Multi-tenant Helm patterns pay off only if every client repo shares the same value contract — aligning Adidas to the UPS Helm pattern unlocked reusable CI/CD.
• Event-driven observability beats log-grep when subsystems cross process boundaries; a dedicated event store is cheap insurance.
• Throughput SLAs are won at the seams between services, not inside any one service.