---
id: ADR-CMT-MTG-003
title: Commit Delivery Work With Business Changes
product_area: committees
module: meetings
revision: 2
status: proposed
design_intent: proposed
source_sha:
  services-committees: 36129c24daeaadcdb339218c38cdeaff9861359d
decision: >-
  The proposed boundary commits durable delivery work with the business change
  and dispatches it afterward, while the current ballot call and
  communication-object preparation still occur inside write transactions.
constrains:
  - SVC-CMT-MTG-meetings
  - SVC-CMT-MTG-decisions
  - SVC-CMT-MTG-recruitment
  - WF-CMT-MTG-001
  - WF-CMT-MTG-004
  - WF-CMT-MTG-005
  - WF-CMT-MTG-014
origin: Observed persistence and outbox design; FND-CMT-MTG-044; FND-CMT-MTG-053
alternatives:
  - option: Invoke providers synchronously while holding business locks.
    why_not: Slow calls lengthen the transaction and can make the business write fail.
  - option: Commit and then make an unrecorded request.
    why_not: A process failure between those steps would lose the work.
consequences:
  - >-
    Delivery can repeat, so recipients and providers must recognize stable
    request keys.
  - >-
    Room and acknowledgement outboxes have no attempt cap or dedicated
    terminal-failure alarm.
  - >-
    The communications boundary writes its queue pointer in the business
    transaction, while preparing the stored object can happen before commit.
supersedes: []
evidence:
  - >-
    services-committees at 36129c24:
    modules/meetings/services/persistence/meeting-room-requests.ts (queued-work
    standard named in the header); modules/meetings/ports/notifier.ts;
    modules/recruitment/services/submissions/acknowledgements.ts;
    lib/events/business-events.ts
---
# Commit Delivery Work With Business Changes

## Context

Rooms, notices, acknowledgements and subscriber effects follow changes to governance records. Durable database work reduces the gap between a successful change and delivery, but does not make every outside action atomic.

## Decision

The proposed boundary commits durable delivery work with the business change and dispatches it afterward, while the current ballot call and communication-object preparation still occur inside write transactions.

## Alternatives Considered

Invoke providers synchronously while holding business locks. Slow calls lengthen the transaction and can make the business write fail.

Commit and then make an unrecorded request. A process failure between those steps would lose the work.

## Consequences

Delivery can repeat, so recipients and providers must recognize stable request keys. Room and acknowledgement outboxes have no attempt cap or dedicated terminal-failure alarm. The communications boundary writes its queue pointer in the business transaction, while preparing the stored object can happen before commit.