Chat system architecture: how to handle message delivery guarantees

we're building a new chat feature for our mobile app, and message delivery guarantees are a huge concern. we need to support read receipts, typing indicators, and reliable offline message delivery. the core dilemma is whether to persist messages to a database first, then publish to kafka for distribution, or publish to kafka first and have consumers handle persistence. kafka-first offers lower latency for producers but introduces challenges around ensuring message persistence if the consumer fails or is slow. database-first guarantees persistence but adds a bit more latency to the user experience. there's a constant tension between reliability and immediate delivery for a real-time system like chat. what patterns have folks used for ensuring 'at-least-once' or even 'exactly-once' delivery semantics in a chat system? how do you handle message ordering, especially when dealing with flaky mobile network connections? any insights on the trade-offs between persisting to a transactional database versus relying on a robust message queue for the initial write path?