Suppose the store runs orders and message delivery as separate services. The orders service records a shipment and publishes an OrderShipped event. A message broker passes that event to delivery services, which contact the email or push notification provider. The services can be deployed separately, so the event becomes a contract between them.
The service boundary
An event connects the services
Orders serviceRecords the shipment
→
OrderShipped eventDelivered by a message broker
→
Email delivery serviceCalls the email provider
Push delivery serviceCalls the push provider
Orders publishes one event. The broker delivers it to each subscribed service; orders does not call either provider.
S
Single Responsibility
Before
Orders serviceTracks shipments and sends email
→
After
Orders serviceTracks shipments
↓
Email delivery serviceSends email
The two services can change and deploy for different reasons.
The orders service owns shipment status; the email delivery service owns sending email. A change to email retries can be deployed without changing the service that records shipments.
O
Open/Closed
Orders servicePublishes OrderShipped
↓
Message broker
↓
Email delivery service
Push delivery serviceNew subscriber
A new service subscribes to the event. The orders service still publishes the same event.
The orders service publishes OrderShipped without naming its subscribers. A push delivery service can subscribe to the same event without adding a push call to the orders service.
L
Liskov Substitution
Current service
OrderShipped eventEvent ID identifies this event
↓
Email service v1Handles repeated event IDs
→
Replacement service
Same OrderShipped eventSame event ID
↓
Email service v2Still avoids duplicate email
Replacing a service must preserve the behavior the rest of the system relies on.
A new version of the email delivery service must honor the same event contract as the old one. If an event is delivered again, it must not send the customer a second email.
I
Interface Segregation
Before
All order changesShipments, payments, refunds
↓
Email delivery serviceFilters unrelated events
→
After
OrderShipped eventsShipment data only
↓
Email delivery serviceReceives relevant events
The delivery service subscribes only to the event type it needs.
The email delivery service needs shipment events, not every change to an order. A focused OrderShipped event keeps payment and refund data out of its contract.
D
Dependency Inversion
Shared contract
Orders service
↓
Delivery services
↓
OrderShipped eventApplication-owned contract
Services agree on the event format. Provider details stay in the delivery services.
The orders service and delivery services share the OrderShipped event contract. Provider SDKs and credentials stay inside the delivery services, so order processing does not depend on a particular provider.
Putting it into practice
The cost of a service boundary
Separate services need reliable event delivery, retries, and compatible event formats. Those costs make sense when teams need to deploy or operate the services independently. Otherwise, the same responsibilities can stay separated inside one application.