Idempotent consumer patterns for RabbitMQ in Python — handling duplicate deliveries under partition

We're running a Python consumer group against RabbitMQ and seeing occasional duplicate message deliveries during network partitions. We've implemented idempotency keys with a Redis-backed dedup cache, but the cache TTL vs processing latency trade-off is tricky. How are you handling idempotent consumers in production? Are you using a persistent store (Postgres unique constraint) vs. in-memory dedup? What TTLs are realistic for your dedup windows? Context: Python 3.12, aio-pika, ~500 msg/s peak, Redis 7 cluster. Jurisdiction: General engineering practice.