ADR-0002: Use AWS SQS for Asynchronous Inter-Service Communication. (from ChatGPT)

Status

Accepted

Date

2026-08-31

Context

As Deal Engine extracts capabilities from the existing monolith into independent services, some workflows no longer require synchronous request/response communication.

Operations such as refund processing may involve slow or temporarily unavailable external systems such as GDS and airline APIs. Using synchronous HTTP for these workflows creates runtime coupling: if the downstream service is unavailable or slow, the upstream service is also affected.

Deal Engine already operates its infrastructure primarily on AWS. We need a reliable asynchronous communication mechanism that integrates with the existing platform without introducing unnecessary operational complexity.

Decision

We will use Amazon SQS as the default mechanism for asynchronous point-to-point communication between services.

Synchronous HTTP will remain for operations where the caller requires an immediate response.

Consumers must assume at-least-once delivery and therefore be designed to handle duplicate messages safely.

Alternatives Considered

Apache Kafka

Pros: High throughput, durable event log, strong replay capabilities, stream processing ecosystem.
Cons: Higher operational and conceptual complexity than required for our current workloads.
Why rejected: We primarily need reliable asynchronous work distribution, not event streaming or long-term event replay.

RabbitMQ

Pros: Mature messaging platform with flexible routing capabilities.
Cons: Introduces another infrastructure technology and operational model.
Why rejected: SQS provides the required queueing capabilities and integrates naturally with our existing AWS infrastructure.

Synchronous HTTP

Pros: Simple request/response model and immediate results.
Cons: Runtime coupling, failure propagation, and poor fit for long-running external operations.
Why rejected: It remains appropriate for synchronous workflows but not as the default for asynchronous processing.

Consequences

Positive

Services are less runtime-coupled.
Temporary consumer outages do not necessarily cause upstream failures.
Consumers can process and scale independently.
Fully managed AWS service with minimal operational overhead.
Natural fit with Deal Engine’s existing AWS infrastructure.

Negative

Asynchronous workflows introduce eventual consistency.
SQS provides at-least-once delivery, so consumers must handle duplicates.
Distributed asynchronous workflows require stronger observability and correlation.
Engineers must account for queue-specific concepts such as visibility timeout and message retention.

ADR-0024: Idempotency Strategy for SQS Consumers
ADR-0025: Transactional Outbox for Reliable Message Publication
ADR-0026: Dead-Letter Queue and Retry Strategy
ADR-0027: Use SNS for Event Fan-Out