This post details how that effort led to introducing Redis to our architecture, and the lessons we learned running Redis at scale.

Denis Bolkovskis

Mental Health

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

Mattermost scaled to over 100K users by introducing Redis into their architecture, addressing issues related to cache invalidations and node synchronization. They opted for the rueidis library for better default functionalities and discovered the importance of batching commands to reduce overhead. Client-side caching was implemented to minimize application latency. They also highlight lessons learned with Redis commands like MGET/MDELETE and using SCAN efficiently, and provide insights on the use of Redis pub-sub mechanism.

Lessons learned from running Redis at scale

Use client-side caching for best of both worlds 💺

Use MGET/MDELETE if you have tight loops with GET/DELETE ➰

Be careful of high volumes of SCAN calls 📈

Ensure not to self-send a message while using pub-sub 🖇️