Nice follow-up to the outbox post. One thing that often gets skipped is how long you keep rows in the inbox table. If you purge them after a day but a consumer was down for longer, or someone replays the topic from an older offset, the duplicate comes back after its row is gone. Tying retention to the longest replay you'd ever do, not to table size, avoids that.
Also curious whether you store a hash of the payload next to the event ID. Same ID with a different body usually means a bug upstream, and it's nicer to log it than to silently drop it as a duplicate.
1
u/AhmedZNOUDA 1d ago
Nice follow-up to the outbox post. One thing that often gets skipped is how long you keep rows in the inbox table. If you purge them after a day but a consumer was down for longer, or someone replays the topic from an older offset, the duplicate comes back after its row is gone. Tying retention to the longest replay you'd ever do, not to table size, avoids that.
Also curious whether you store a hash of the payload next to the event ID. Same ID with a different body usually means a bug upstream, and it's nicer to log it than to silently drop it as a duplicate.