The outbox pattern provides a solution which doesn’t require distributed transactions. As part of its local database transaction, the appointment service inserts the notification message which it wants to send into a table in that database. A separate process, called the outbox relay, picks up that message from this outbox table and sends it to Kafka. This happens asynchronously and can be retried if needed, without impacting the clients of the appointment service in any way.

Key implementation details of the Outbox Pattern include choosing between polling vs. log-based CDC for message retrieval, designing the outbox table structure, housekeeping, and leveraging database-specific features like pg_logical_emit_message() in Postgres. It also covers format considerations and the management of backfills.

The criticisms of the Outbox Pattern include concerns about database overhead, complexity, and latency. The database overhead concern is about the additional load put onto a service’s database by using it for storing and emitting outbox messages. The complexity argument includes the overall number of moving parts of the solution as well as their interactions.

Alternatives to the Outbox Pattern include Dapr, Read-yourself, Stream Processing on "Raw" Change Event Streams, 2PC, and Durable Execution. Each alternative has its own trade-offs in terms of consistency, availability, queryability, developer experience, and operational complexity.