Architecture
AuraScore 83/100

Dynamic Last-Mile Routing Engine Modernization Architecture

Decompose monolithic routing workflows into a scalable, event-driven microservices architecture for real-time dispatch and route recalculation.

Use this template when transitioning dispatch and routing platforms to an event-driven microservices model. It produces a comprehensive architectural report covering solver isolation, real-time event distribution, and consistency trade-offs.

Template

Role: Chief Software Architect specializing in logistics optimization and distributed algorithmic systems.

Context

  • Existing monolithic platform: {{legacy_routing_system}}
  • Peak dispatch transaction volume: {{dispatch_volume_peak}}
  • Routing SLA and recalculation limit: {{sla_recalculation_latency}}
  • Mapping and road network integration: {{external_map_data_providers}}
  • Transactional consistency requirements: {{consistency_model_requirements}}
  • Target compute environment: {{deployment_environment}}

Task

Author a comprehensive architectural modernization report detailing the target-state microservices decomposition, solver orchestration, and event-driven data flow for dynamic last-mile route optimization.

Method

  1. Map the bounded contexts of {{legacy_routing_system}} to isolate dispatch, fleet tracking, routing optimization, and driver assignment.
  2. Design the optimization engine interface, isolating computationally heavy Vehicle Routing Problem (VRP) heuristic solvers from synchronous client requests.
  3. Architect the external data ingestion layer for real-time traffic and road closures provided by {{external_map_data_providers}}.
  4. Define asynchronous event orchestration using Saga patterns to manage driver assignment while satisfying {{consistency_model_requirements}}.
  5. Specify caching, spatial indexing, and in-memory routing graph topologies within {{deployment_environment}} to meet {{sla_recalculation_latency}}.
  6. Evaluate fallback pathways and degraded-mode operation when combinatorial solvers exceed latency budgets under {{dispatch_volume_peak}}.
  7. Detail the API gateway contracts, service discovery, and gRPC/REST protocols for mobile driver clients and dispatch consoles.
  8. Produce a zero-downtime strangler-fig migration roadmap from {{legacy_routing_system}} to the target microservices.

Constraints

  • MUST detail exact boundary contexts using Domain-Driven Design (DDD) principles.
  • MUST NOT introduce distributed locking mechanisms that block dynamic re-routing at peak load.
  • MUST define latency budgets for every internal hop to enforce {{sla_recalculation_latency}}.
  • State management models must explicitly justify eventual consistency vs. ACID trade-offs.

Output format

Deliver an in-depth architectural evaluation report containing:

  1. Target State System Landscape & Bounded Context Map
  2. Optimization Solver Isolation & Async Job Execution Flow
  3. Data Synchronization, Spatial Indexing & Cache Invalidation Strategy
  4. Distributed Consistency & Saga Transaction Specifications
  5. Resilience, Throttling & Fallback Architecture
  6. Phased Strangler-Fig Migration Roadmap (4-6 discrete phases)

Self-review

  • Ensure the solver execution lifecycle does not cause thread exhaustion under {{dispatch_volume_peak}}.
  • Validate that all dependencies on {{external_map_data_providers}} include circuit-breaker and rate-limiting patterns.
  • Confirm that the migration roadmap accounts for dual-write verification between legacy and new services.
AuraScore breakdown
83/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.

Robustness5/5 · Strong

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-architecture
transport-logistics
microservices
last-mile
route-optimization