CASE STUDY 01 / MODULAR MONOLITHLAST-MILE LOGISTICS

DELIVERY WITHOUT DROPPED EVENTS.

A production-oriented last-mile delivery platform built as a modular monolith with five independently structured modules, communicating through RabbitMQ and gRPC with Transactional Outbox and Inbox reliability.

5 BOUNDED CONTEXTS TOPOLOGYTRANSACTIONAL OUTBOX / INBOX
01 / MODULE
ORDERS

Order lifecycle and outbox event registration.

02 / MODULE
DRIVERS

Driver availability and synchronous gRPC contracts.

03 / MODULE
DISPATCHING

Internal assignment coordination with drivers.

04 / MODULE
TRACKING

Delivery progression and location updates.

05 / MODULE
NOTIFICATIONS

Deduplicated consumer inbox for status alerts.

  1. 01 / SECTION

    THE PROBLEM

    When asynchronous parts of a system communicate, failures can happen between changing application state and publishing the event that describes that change.

    A dropped event in last-mile logistics means a driver is never notified, a dispatch never happens, or a customer never receives a status update — while the database says everything is fine.

  2. 02 / SECTION

    THE APPROACH

    Transactional Outbox and Inbox patterns keep state changes and message processing reliable while protecting consumers from duplicate message handling.

    Domain events are written inside the same transaction as the state change, then relayed to RabbitMQ through MassTransit. Consumers deduplicate with an inbox so repeated deliveries stay safe.

  3. 03 / SECTION

    MODULE BOUNDARIES

    Five modules — Orders, Drivers, Dispatching, Tracking and Notifications — each own their data and expose explicit contracts instead of sharing internal state.

    Dispatching and Drivers communicate synchronously over gRPC with Protocol Buffers where an immediate answer is required; everything else flows asynchronously over the message bus.

  4. 04 / SECTION

    OUTCOME

    The platform keeps order state and delivery events consistent across modules even when parts of the system fail or retry mid-flow.

    Boundaries stay understandable as the system grows, and each module can be reasoned about, tested and evolved independently.

TECHNICAL STACK
  • .NET 9
  • C#
  • DDD
  • CLEAN ARCHITECTURE
  • MODULAR MONOLITH
  • RABBITMQ
  • MASSTRANSIT
  • GRPC
  • PROTOCOL BUFFERS
  • POSTGRESQL
  • DOCKER