# ADR-001: Use Event-Driven Backbone for AMI Meter Reads

- **Status:** Accepted
- **Date:** 2026-08-14
- **Deciders:** Enterprise Architecture Board
- **Tags:** integration, ami, kafka, event-driven

## Context

The AMI head-end produces 40+ million interval reads per day. SAP IS-U
billing jobs cannot absorb synchronous bursts, and multiple consumers
(billing, VEE analytics, outage management, data lake) need the same facts
independently. A point-to-point synchronous design would make every new
consumer a change to the head-end publisher.

## Decision

Adopt an event-driven backbone (Apache Kafka) as the single distribution
layer for meter-read facts. The head-end publishes `meter.read.interval`
events once; each consumer maintains its own offset, schema version, and
replay window.

## Alternatives Considered

| Option | Why not |
| --- | --- |
| Synchronous REST to IS-U | Couples collection rate to IS-U availability; burst failures |
| Scheduled file transfer (SFTP) | Hourly latency unacceptable for outage detection |
| ESB request-reply | Centralised throughput bottleneck; single point of failure |

## Consequences

**Positive**
- Temporal decoupling: IS-U downtime no longer blocks collection
- New consumers onboard without producer changes
- 30-day replay window enables reprocessing after data-quality fixes

**Negative**
- Eventual consistency must be explained to billing stakeholders
- Schema governance (registry + compatibility rules) is now mandatory
- Operational investment: lag monitoring, DLQ triage runbooks

## Compliance

Review after 12 months or when daily volume exceeds 100M reads.