# ADR 0001: Keep background email jobs in the existing database

Fictional worked example. The workload figures are assumptions for this example, not measured results or claims about a real project.

## Decision

We propose storing pending email jobs in the application's existing PostgreSQL database instead of introducing a separate message broker for the first release.

## Context

Decision owner: the example application team.
The application already operates a database and has one deployment team. We assume at most 100 email jobs per minute initially. We have not load-tested that workload. Email delivery must not block an interactive request.

## Alternatives rejected

- Synchronous sending: a slow email provider would delay the interactive request.
- A separate broker: it may become appropriate for higher throughput or independent consumers, but adds a service to operate before that need has been demonstrated.

## Consequences accepted

We must implement retry limits, idempotent processing, and observability for waiting and failed jobs. Database outages also affect job processing. The design does not promise exactly-once delivery.

Before acceptance, test worker failure during processing, provider timeouts, duplicate attempts, and the assumed workload. Revisit the choice if queue processing materially degrades interactive database queries or additional consumers need independent delivery.

## Status

Proposed. Not yet accepted or performance-tested.

If the decision changes, create a new record and link the two; preserve the original context.

---
Guide: https://softwaremadeclear.com/architecture-decision-records/