Skip to content

Implement outbox pattern #3

Description

@simonforsberg

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Persist-and-publish flow is non-atomic and can desynchronize state.

If RabbitMQ publish fails after Line 31, the message is stored but no event is emitted; retries can also duplicate effects. Use an outbox/transactional publishing strategy to guarantee eventual publish consistency.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@messageService/src/main/java/org/example/messageservice/service/MessageService.java`
around lines 31 - 34, The persist-and-publish call in MessageService
(messageRepository.save followed by rabbitTemplate.convertAndSend) is non-atomic
and can lead to lost or duplicated events; change to a transactional outbox
pattern: in the same DB transaction that calls messageRepository.save create and
persist an OutboxRecord entity (e.g. OutboxMessage) storing the message id and
payload, then remove direct rabbitTemplate.convertAndSend from the save flow;
implement a separate publisher component (a scheduled or change-data-capture
worker) that reads pending OutboxRecord rows, publishes them via
rabbitTemplate.convertAndSend (using RabbitMQConfig.QUEUE_NAME),
marks/outbox-records-as-sent with retries and idempotency safeguards, and ensure
all DB writes use the same transaction boundaries so messageRepository.save and
the OutboxRecord persist are atomic.

Originally posted by @coderabbitai[bot] in #2 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions