A public sector agency ran Redis for several workloads with different durability needs but a single inherited configuration. Nobody could state which data survived a host failure and which did not. AceMQ assessed the deployment against each workload's real requirements.
Redis persistence options trade durability against latency in ways that are easy to misconfigure and hard to notice until a failure. The agency's instances used snapshot intervals that would lose minutes of writes, while some workloads had been assumed durable. Replication and failover had never been tested, so promotion behavior and data loss on failover were unknown.
On-premises Redis instances with Sentinel-managed failover, supporting caching, queuing, and session workloads.
AceMQ classified each workload by what loss it could actually tolerate, then compared that against what the current configuration guaranteed. Failover was exercised deliberately, with data loss measured rather than estimated, so the gap between assumption and behavior was documented with evidence.
The agency received a documented, evidence-backed statement of what each workload survives, replacing an assumption that had never been tested. Two workloads believed to be durable turned out not to be, and were reconfigured before a failure demonstrated it.
Planning a migration from vertically scaled standalone Redis to Cluster mode, including hash tag design and remediation of cross-slot operations.
Ongoing support for instances where the eviction policy did not match how the keyspace was used, causing session data to be evicted under memory pressure.
Whether you need architecture advisory, 24/7 support, or full managed services, AceMQ has the expertise to help.