# 1. Use events between the order and billing services

Date: 2026-10-28

## Status

Accepted

## Context

**Question:** How should the order and billing services communicate?

**Must:**
- Orders aren’t lost if billing is unavailable
- Each order is billed exactly once

**Should:**
- The current team can run it without new specialist tools

**Options considered:**
- Publish events (chosen)
- Message queue (runner-up)
- Direct API calls
- Shared database

## Decision

Chosen option: Publish events.

We chose to publish events because it supports orders being preserved when billing is unavailable. Compared with the runner-up, a message queue, it allows billing and other services to subscribe rather than directing a billing request to a queue.

## Consequences

- We enable other services to subscribe to order events.
- We must verify duplicate-event handling before rollout to support exactly-once billing.

Recorded with Decided · decisionrecords.app