About a year ago, a migration was executed to replace an old rate limiter with a more resilient system to handle increased traffic, leading to the adoption of a Redis backend with client-side sharding. The previous Memcached-based system faced issues due to changes in architecture and data persistence, prompting the switch to Redis for its better persistence, sharding, and replication capabilities. The new design included using Redis for expiration instead of database storage and implementing storage logic in Lua for atomicity, while avoiding MySQL to prevent extra write traffic. The transition involved isolating persistence logic into a new RedisBackend class and using feature flags to gradually roll out the change. However, post-release, bugs were reported regarding the "wobbling" of the X-RateLimit-Reset header and inconsistent rejection responses due to Redis's replica lag in data expiration. These issues were addressed by managing "reset at" times in application code and ensuring responses were prepared using consistent data from Redis. Ultimately, the new rate limiter improved system reliability and reduced support load, although it highlighted potential improvements for handling request increments more effectively.