Backend & APIs
AuraScore 81/100

Freight Dispatch Event-Driven Decomposition Strategy

Create a migration and architecture plan to transition legacy monolithic dispatch systems into event-driven microservices.

Apply this prompt when legacy transportation management monoliths choke under dynamic shipment rerouting and load matching. It generates a phased decoupling roadmap using domain-driven design and transactional outbox patterns.

Template

Role: Staff Distributed Systems Architect specializing in supply chain core systems modernization.

Context

  • Monolithic core engine: {{legacy_dispatch_engine}}
  • Target event backbone: {{target_broker_technology}}
  • Daily shipment message volume: {{shipment_event_volume}}
  • Upstream and downstream dependencies: {{erp_dependency_matrix}}
  • Maximum allowable migration downtime: {{cutover_downtime_window}}
  • Data consistency requirement: {{consistency_model}}

Task

Develop a comprehensive architectural migration and implementation plan to decouple {{legacy_dispatch_engine}} into autonomous, domain-driven microservices utilizing {{target_broker_technology}}, ensuring zero data corruption across {{erp_dependency_matrix}} during cutover.

Method

  1. Conduct domain boundary mapping on {{legacy_dispatch_engine}}, isolating load matching, driver assignment, rate calculation, and shipment status domains.
  2. Design change data capture (CDC) and transactional outbox patterns to mirror database state to {{target_broker_technology}} without introducing two-phase commit overhead.
  3. Construct an anti-corruption layer (ACL) interface preserving operational stability for {{erp_dependency_matrix}} during dual-write phases.
  4. Define idempotent event consumer schemas, dead-letter routing, and deduplication logic capable of handling {{shipment_event_volume}} with {{consistency_model}} guarantees.
  5. Formulate an incremental Strangler Fig migration schedule, mapping cutover stages by domain complexity.
  6. Detail automated data reconciliation scripts to detect and reconcile divergence between legacy stores and new microservice datastores in real time.
  7. Plan canary release gating and immediate rollback mechanisms fitting inside {{cutover_downtime_window}}.

Constraints

  • MUST NOT require halting active freight bookings during data migration stages.
  • MUST define explicit compensation transactions (Saga pattern) for distributed business workflows.
  • Microservices MUST be decoupled such that failure in rate calculation does not block active driver tracking or order acceptance.
  • All message contracts MUST be defined using strict backward-compatible schema versioning.

Output format

  • Section 1: Domain Boundary & Event Contract Blueprint (mapping domains, events, and schema structures)
  • Section 2: Data Replication & Synchronization Architecture (CDC, Transactional Outbox, and ACL designs)
  • Section 3: Saga Orchestration & Distributed State (step-by-step workflow with compensation steps)
  • Section 4: Phased Cutover & Reconciliation Roadmap (Gantt-ready timeline with validation milestones)
  • Keep total output between 1,400 and 2,000 words.

Self-review

  • Ensure the migration approach complies strictly with {{cutover_downtime_window}}.
  • Validate that all dependencies in {{erp_dependency_matrix}} have defined ACL interfaces.
  • Verify that the transactional outbox and event schemas preserve {{consistency_model}} across all distributed services.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-backend-apis
transport-logistics
microservices
event-driven
system-migration