# Redis persistence, replication, and latency issues discussed after Stripe's report

DevFeed: [Redis persistence, replication, and latency issues discussed after Stripe's report](<https://devfeed.tech/articles/this-is-why-i-can-t-have-conversations-using-twitter-20673.md>)

Original publisher: [Read original article](<http://antirez.com/news/82>)

Published: 2014-10-29T09:17:04Z

Content type: opinion

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Redis](<https://devfeed.tech/topics/redis.md>), [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [Amazon EC2](<https://devfeed.tech/topics/amazon-ec2.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [Persistence](<https://devfeed.tech/topics/persistence.md>), [Databases](<https://devfeed.tech/topics/databases.md>)

Tags: [database](<https://devfeed.tech/tags/database.md>), [ec2](<https://devfeed.tech/tags/ec2.md>), [latency](<https://devfeed.tech/tags/latency.md>), [persistence](<https://devfeed.tech/tags/persistence.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [redis](<https://devfeed.tech/tags/redis.md>), [replication](<https://devfeed.tech/tags/replication.md>), [scale](<https://devfeed.tech/tags/scale.md>)

## AI overview

The article discusses Stripe's reported issues with Redis, including latency behavior on EC2 and the comparison with PostgreSQL. It explains how diskless replication changes Redis persistence design constraints and suggests that some high-percentile latency problems may result from infrastructure-related spikes.

## Source excerpt

Yesterday Stripe engineers wrote a detailed report of why they had an issue with Redis. This is very appreciated. In the Hacker News thread I explained that because now we have diskless replication (http://antirez.com/news/81) now persistence is no longer mandatory for people having a master-slaves replicas set. This changes the design constraints: now that we can have diskless replicas synchronization, it is worth it to better support the Stripe (ex?) use case of replicas set with persistence turned down, in a more safe way. This is a work in progress effort. In the same post Stripe engineers said that they are going to switch to PostgreSQL for the use case where they have issues with Redis, which is a great database indeed, and many times if you can go with the SQL data model and an on-disk database, it is better to use that instead of Redis which is designed for when you really want to scale to a lot of complex operations per second. Stripe engineers also said that they measured the 99th percentile and it was better with PostgreSQL compared to Redis, so in a tweet @aphyr wrote: "Note that *synchronous* Postgres replication *between AZs* delivers lower 99th latencies than asynchronous Redis" And I replied: "It could be useful to look at average latency to better understand what is going on, since I believe the 99% percentile is very affected by the latency spikes that Redis can have running on EC2." Which means, if you have also the average, you can tell if the 99th percentile is ruined (or not) by latency spikes, that many times can be solved. Usually it is as simple as that: if you have a very low average, but the 99th percentile is bad, likely it is not that Redis is running slow because, for example, operations performed are very time consuming or blocking, but instead a subset of queries are served slow because of the usual issues in EC2: fork time in certain instances, remote disks I/O, and so forth. Stuff that you can likely address, since for example, ther