Glide faced multiple challenges in scaling their real-time messaging platform. One major challenge was the need for real-time reminders and analytics. Every time a user received a message, a reminder had to be created, requiring push notifications in real-time. This necessitated persistent in-memory storage across servers and real-time aggregated analytics to support admin performance reports. Another challenge was a client-side bug that caused session tokens to be corrupted, leading to new login requests for every interaction. This resulted in a 'memory leak' in Redis, causing unnecessary data volume growth. Lastly, Glide faced issues with Pubnub message counters due to the large volume of messages created daily, which exceeded expected limits.

Before adopting Redis, Coffee Meets Bagel was struggling with its implementation of Cassandra. While Cassandra delivered on basic high write volume requirements, it experienced noticeable issues when it came to simultaneous updates and deletions, resulting in partial outages that impacted end-user experience. As a result, Coffee Meets Bagel moved to open source Redis, running as self-managed clusters, to deliver low read latency while simultaneously tolerating high update volume. Although the company initially adopted Redis as delivered via Amazon ElastiCache, as its Redis implementation grew to become an integral part of Coffee Meets Bagel’s production environment, the DevOps team realized that it would be extremely beneficial to have a fault-tolerant, highly available and scalable solution with someone to call when problems arose. With open-source Redis, you’re on your own and there’s a lot of trial and error that takes place, which is not ideal in a production environment.

Before Redis Enterprise, the BioCatch operations teams were struggling to keep pace with the company’s rapid growth. As the platform reached and then surpassed five billion transactions per month, the issue of scaling consumed everyone’s attention, leaving no resources to focus on new product features. “Version one of our solution was built to go to market very fast,” says Dekel Shavit, BioCatch VP of Operations & CISO. “It wasn’t designed with 70 million users in mind and so efficient architecture and data models weren’t initially top of mind.” But it was clear that a redesigned technology stack needed to be top of mind for the solution’s next incarnation. Of particular priority was decoupling compute and state to make the system more elastic. Session state was being kept across many virtual machines; if a machine fell down, all of its sessions were lost. This configuration was not only proving to be a liability within the context of critical real-time fraud detection, but also very difficult—and expensive—to scale.

Inovonics, a leader in wireless sensor networks for life safety applications, faced the challenge of harnessing the vast amounts of data collected by its devices. The data was previously siloed, limiting its potential for actionable insights. The company needed a robust data platform to centralize this data, reduce operational overhead, and provide high performance and resiliency. Additionally, Inovonics sought to leverage this data for new product offerings, such as predictive maintenance analytics and insights into security risks, while minimizing the operational footprint and costs.

With just three weeks to go before a big marketing event designed to deliver a significant increase in user activity, Netmeds was desperate to resolve the failure issues that were currently plaguing its Amazon ElastiCache. Huge spikes in user traffic were choking Redis with too many connections, causing it to fail. As a result, Netmeds would experience downtimes of up to an hour that easily lost them 750 orders every 30 minutes. Netmeds initially thought the issue could be resolved through clustering on ElastiCache, but the company’s PHP platform did not support clustering of Redis. Next, NetMeds evaluated connection management solutions as a way to reduce the number of open database connections. They looked at Twemproxy, Dynomite, and HAProxy in an attempt to set up connection pooling, but none of these solutions supported every command that Redis supported.

Freshworks experienced significant growth, with a 50% year-over-year increase and over $100 million in annual recurring revenue. This rapid expansion strained their application architecture and development operations, particularly their MySQL database. The existing caching solution, Amazon ElastiCache, was inadequate, requiring extensive manual effort for data migration and causing delays in the product development lifecycle. Freshworks needed a more efficient and scalable solution to handle the increasing database load and improve application responsiveness.

Users of Whitepages’ people search and identity verification services expect instant results from a single piece of contact information, which requires a highly efficient and fast database system. The company's proprietary Identity Graph™ database, which houses billions of person-identity records, generates a high volume of calls to Redis, especially during peak times. Initially, Whitepages used Amazon ElastiCache to store IDs, but as the company expanded globally, this solution became resource-intensive and unwieldy. The company evaluated MongoDB, Apache Cassandra, and Couchbase as potential replacements, but none could handle the full dataset size while providing the required single-digit latency. Whitepages' applications are extremely latency-sensitive, and customer SLAs promise sub-hundred millisecond latency, leaving no room for error.

Dynamic Yield faced significant challenges as it scaled its operations. Initially, the company used open source Redis as a simple, local cache. However, as the user base and application portfolio grew, Redis evolved into a core component of their operations, touching almost every feature of the platform. By 2016, the database had grown from ten to 400 gigabytes, making scaling a pressing issue. The company needed to maintain the ease of use, high performance, and flexibility it enjoyed with Redis while addressing these scaling challenges. Additionally, by 2018, Dynamic Yield was overseeing more than a terabyte of data, organized in three Redis clusters with approximately 15 nodes per cluster. Database maintenance and associated development operations were becoming too time-consuming, necessitating a more efficient solution.

Before Redis Enterprise, Malwarebytes was struggling to harness the sheer enormity of data their systems were capturing. The company had access to a wealth of malware data, but leveraging that data with the speed and efficiency necessary to drive intelligence into global and local attack vectors was a daunting task. One of the challenges at hand was to create stateful storage for several of Malwarebytes’ lifeblood data streams. They received billions of records of malware detection information, and as malware was detected, threat details were streamed to a centralized data platform. Stateful environment information was also streamed and collected separately in stateful storage for streaming data joins. Understanding environment state as malware detections were found in real-time was game-changing, providing deep insights into malware proliferation, velocities, and attack vectors that were previously impossible. Additionally, Malwarebytes’ advanced visualizations posed another big storage challenge. The visualizations provided an analysis of outbreak geography, velocities, and even insights into gestational periods of early malware formation. However, they were built on vast amounts of data and required tremendous amounts of compute resources to generate, necessitating a database that could provide centralized stateful storage and perform real-time streaming joins at a massive scale.

In late 2014, Etermax’s online Trivia Crack game went viral, leading to a rapid increase in users. The company faced significant challenges with its existing open source Redis installation, including CPU bottlenecks, memory limitations, and high costs for maintaining a redundant infrastructure. The single-threaded nature of Redis and the inability to utilize all cores of the largest AWS instances further exacerbated the problem. Etermax needed a solution that could handle the high availability and performance demands of its growing user base, which was increasing by two to three million new users every week.

Microsoft Network Services (MSN) faced significant challenges in managing high traffic volumes, especially during peak times when traffic could reach up to 2 billion. The primary issues included high latency and slow response times from other databases, which were unable to handle the required volume and throughput of data. These performance bottlenecks necessitated a robust solution to ensure smooth and efficient operation of their applications, particularly during traffic spikes.

eHarmony faced significant challenges with its legacy data store, Voldemort, which struggled to meet the real-time personalization demands of the matchmaking service. The key issues included ever-growing key sizes due to Voldemort's plain key-value store limitations, less than ideal performance as the user base grew, and a lack of community support since Voldemort was originally developed by LinkedIn engineers and never received enterprise backing. These challenges made it difficult for eHarmony to maintain high performance and seamless, real-time customer experience, risking customer loss due to delays in displaying matches.

Rumble Entertainment faced several business challenges that led them to evaluate and ultimately select Redis Labs. They required high availability with features like persistence, auto-failover, and cross-zone/multi-region/multi-datacenter in-memory replication. Additionally, they needed seamless scaling and clustering, along with robust monitoring and management capabilities, including alerting and dashboards. The company also sought 24×7 support for their mission-critical Redis layer, stable high performance, and deep operational and technical expertise.

Staples Business Advantage faced significant challenges with high latency and slow response times from their existing databases. These databases were also limited in their ability to handle high volumes and throughput of data, which was a critical requirement for Staples. The company needed a solution that could provide faster response times and handle larger datasets efficiently.

LifeLock needed a database with key-value store functionality and high availability. For LifeLock’s identity protection, it’s imperative that client authentication be delivered in real-time. Fraud mitigation requires continuous processing and analysis of millions of transactions or user profiles. Most other databases they were considering were either designed for slower analytics or couldn’t deliver fast enough response times. Additionally, LifeLock has many database platforms running concurrently and continues to grow. Having to cover all these platforms is challenging and when looking for a solution other traditional or NoSQL databases required a great deal of complex application development to provide functionality. Here are some additional business challenges that led LifeLock to evaluate and ultimately select Redis Enterprise: Values Redis Enterprise’s ability to provide: High availability- persistence, auto-failover, cross-zone/multiregion/multi-datacenter in-memory replication Seamless scaling & clustering 24×7 support for mission critical Redis layer Stable, high performance

Twitch, the world’s leading social video platform and community for gamers, faced the challenge of managing an extremely high volume of concurrent users. With over 100 million community members and up to 2 million concurrent visitors, Twitch needed a robust solution to handle their website-wide chat functionality. The chat rooms often scaled up to 400,000+ users, requiring low latency and high availability to ensure a seamless user experience. Additionally, Twitch's engineering team sought operational simplicity and reliability to focus on delivering the best possible experience to their users.

Prior to using Redis Enterprise, Turner Broadcasting began to encounter the same challenges that typically accompany an out-of-date database. As it looked to the future, Turner wanted to break up its media analytics into different microservices. Unfortunately, Turner’s original database wasn’t able to work within its desired framework; not only was the framework too complex, but also the database experienced high latency as it tried to handle spikes in traffic. Below are the challenges that led Turner Broadcasting to evaluate and ultimately select Redis Enterprise: Encountered the following challenges before choosing Redis Enterprise: High latency and slow response times from other databases Other databases only being able to handle limited volume and low throughput of data Other databases not being able to work within the microservices framework and are too complex for new application development

Didstopia faced multiple issues with their previous database: it lacked security control, was too complex for new application development, and couldn’t work within their microservices framework. The business challenges that led the profiled company to evaluate and ultimately select Redis Enterprise included other databases not being able to work within the microservices framework and being too complex for new application development, as well as a lack of security control with other databases.

In order to meet the rigorous standards of next-generation applications, businesses need to adopt analytics inline to generate an intelligent customer experience. Therefore, MedeAnalytics needed to guarantee a high level of performance for its customer-facing analytics platform. In order to accomplish that, MedeAnalytics needed high-performance databases that were capable of handling a variety of application scenarios. Below are the business challenges that led MedeAnalytics to evaluate and ultimately select Redis Enterprise: Encountered the following challenges before choosing Redis Enterprise: High latency and slow response times from other databases.

Prior to using Redis Enterprise, Fortifi ran Open Source Redis inside a Kubernetes Engine cluster. Managing it wasn’t too difficult, but it wasn’t built quite right from the outset. It would occasionally fail over and nodes would lose sync with each other. As its application and user count grew, Fortifi realized it needed a cost-effective method of ensuring that customers’ experience with its application didn’t diminish. Fortifi encountered issues with their Redis setup, including occasional failovers and nodes losing sync, which impacted the user experience. They needed a more reliable and scalable solution to handle the growing application usage and user count.

Real, a technology-powered brokerage platform for real estate agents, faced significant challenges as its user base grew. The company experienced difficulties with its existing databases, which were unable to efficiently operate within a microservices framework. These databases were also too complex for new application development, leading to issues in scaling and administration. Real needed a database solution that could manage its microservices environment and provide stable performance for its social channels.

Editoo’s promise to customers is a professional-grade magazine produced in a short amount of time. When customers first visited Editoo’s website, they were met with slow response times and high latency. This was a problem; a fast user interface is crucial to retaining a customer’s attention, especially if speed is part of a company’s mission statement. Below are the challenges that led Editoo to evaluate and ultimately select Redis Enterprise: Encountered the following challenges before choosing Redis Enterprise: High latency and slow response times from other databases.

Revmob faced significant challenges with their previous databases, including data loss and downtime, which hindered their operations. The difficulty in operating, scaling, and administering these databases further compounded their issues. These challenges prompted Revmob to seek a more reliable and scalable solution to support their growing business needs.

The business challenges that led the profiled company to evaluate and ultimately select Redis Labs included the need for high availability, persistence, auto-failover, cross-zone/multiregion/multi-datacenter in-memory replication, seamless scaling & clustering, and stable, high performance.

Udemy faced significant challenges with their previous database solutions, including data loss and downtime. These issues were critical as they impacted the user experience and the company's ability to scale effectively. The difficulty in operating, scaling, and administering other databases led Udemy to seek a more robust solution. The need for a database that could handle real-time analytics, high-speed transactions, and a growing user base was paramount. Additionally, the company required a solution that could support multiple locations and data models, ensuring seamless scalability and high availability.

Advent Health Partners faced significant challenges with high latency and slow response times from other databases, which led to data loss and downtime. Additionally, they encountered difficulties in operating, scaling, and administering these databases. These issues were critical as they impacted the company's ability to deliver maximum financial returns and operational insights to its clients.

The Utilitywise IoT application streams live data from buildings, enabling users to control their business energy assets from their phones. The application operates physical devices in buildings including lighting, heating, and ventilation systems. The Utilitywise IoT application requires extremely fast data ingest as well as rapid processing of data for analytics. The application uses a Microsoft SQL Server and Datastax Cassandra backend, but needed a higher performance database technology to enable it to easily scale.

Infosys faced significant challenges with their previous database solutions, which were unable to handle the high volume and throughput of data required for India's new taxation system. They experienced data loss and downtime, and found it difficult to operate, scale, and administer these databases. These issues prompted Infosys to seek a more robust and scalable solution to ensure the stability and efficiency of the taxation system for 1.2 billion people.

The business challenges that led the profiled company to evaluate and ultimately select Redis Enterprise included high latency and slow response times from other databases, as well as difficulty operating, scaling, and administering other databases. These issues were critical as Skydrop needed a reliable and efficient database solution to handle real-time weather data for their smart sprinkler controller. The company faced significant operational hurdles with their previous database systems, which could not meet the demands of their growing application usage and user count. The need for a high-performance, scalable, and easy-to-administer database solution was paramount to ensure the efficient functioning of their IoT water conservation solution.

Qin Yu, Director of Engineering at Xignite.com, was faced with the pressures of delivering a technology architecture that could handle the massive volume of financial market data with sub-millisecond latencies. A thorough understanding of databases and their best use cases was required to curate the best technology solution for Xignite. Open Source Redis was an obvious choice for any data that required fast access, as well as complex computations via in-memory analytics. Qin chose Redis for its versatile data structures, commands and Lua scripting support, which made it the simplest, fastest way to crunch the data delivered by Xignite. But outages had the potential to wreak havoc and could cost the company dearly. As Xignite’s client base grew, it was more important than ever to reduce downtime. Qin had to find a way to reliably scale the business’ usage of Redis while mitigating the risk of downtime or data loss.