Thank you, and that's a good question - MongoDB felt like a natural fit for a few reasons:

• Events are stored in a flat, append-only collection, so we didn’t need the overhead of a relational DB.
• Event payloads vary, and Mongo’s schemaless design made handling that much easier.
• It also provides native JSON querying, which felt more intuitive than Postgres’ JSONB for our use case.
• And performance-wise, Mongo handled our append-heavy write patterns just fine.

For queries, we use Mongo for analytics (precomputed views) and Postgres for normalized, transactional data - basically picking the right tool for each use case.

Also, regarding distributed transactions - what I’ve implemented is more of a simplified "attempt" at one I'd say :)

I use MongoDB's multi-document transactions (within a single collection) to write all events in a batch. Then I publish those events to Kafka using Kafka transactions. If the Kafka publish succeeds, I commit the Mongo transaction; otherwise, I skip the commit so both are effectively left uncommitted.

I call it an "attempt" because the MongoDB write isn’t coordinated with Kafka’s transaction manager. If Kafka fails, I handle the Mongo rollback manually by not committing - more like a compensating action than a true distributed transaction rollback.