SNS & outbox pattern

SNS by itself does not automatically implement or replace the outbox pattern, though it can be part of an outbox pattern implementation.

Here's why:

  1. The Outbox Pattern's Purpose:

    • Ensures data consistency between database transactions and message publishing

    • Maintains exactly-once message delivery semantics

    • Preserves message ordering when needed

    • Provides recovery capabilities after system failures

  2. SNS Characteristics:

    • Provides at-least-once delivery guarantee

    • Doesn't participate in database transactions

    • Messages sent to SNS are independent of your database state

    • Can't roll back a message once published

  3. Key Issue: The fundamental problem the outbox pattern solves is the atomic consistency between database changes and message publishing. SNS doesn't provide transactional guarantees with your database operations. For example:

    // This is not atomic
    db.save(order);
    sns.publish(orderCreatedEvent); // What if this fails?
  4. Common Scenarios Where Outbox Is Still Needed with SNS:

    // Using outbox with SNS
    @Transactional
    public void createOrder(Order order) {
        orderRepository.save(order);
        outboxRepository.save(new OutboxEvent("OrderCreated", order));
    }
    
    // Separate process/lambda that polls outbox
    public void processOutbox() {
        List<OutboxEvent> events = outboxRepository.findUnprocessed();
        for (OutboxEvent event : events) {
            sns.publish(event.getTopic(), event.getPayload());
            outboxRepository.markAsProcessed(event.getId());
        }
    }
  5. Alternative Approaches:

    • Using DynamoDB Streams or RDS Event Notifications

    • Change Data Capture (CDC) patterns

    • Event sourcing with event stores

    • Using Amazon EventBridge with reliable message delivery patterns

However, there are some specific cases where you might not need an outbox pattern even when using SNS:

  • When eventual consistency is acceptable

  • When duplicate messages can be handled by consumers

  • When message loss is tolerable

  • In simple workflows where transactional consistency isn't critical

The key is understanding your system's requirements around:

  • Data consistency

  • Message delivery guarantees

  • Recovery capabilities

  • Message ordering requirements

If any of these are critical to your system, you'll likely still need to implement an outbox pattern or similar mechanism, even when using SNS as your messaging infrastructure.

Last updated

Was this helpful?