In my current workplace, we use Redis for various purposes, including managing query caches, queues, and as a registry for different system components. These components register themselves when live, enabling efficient usage tracking.

Previously, at another company, we used Redis to cache machine learning models, facilitating model delivery across platforms without frequent disk retrieval.

In my current workplace, we use Redis for various purposes, including managing query caches, queues, and as a registry for different system components. These components register themselves when live, enabling efficient usage tracking.

Previously, at another company, we used Redis to cache machine learning models, facilitating model delivery across platforms without frequent disk retrieval.

Redis provides an easy setup and operation process, allowing users to quickly connect and use it without hassle. We primarily use Redis as a caching system due to its multiple data types and PubSub features, offering efficient data handling. Redis's PubSub capabilities benefit our communication by facilitating thread intercommunication. It allows multiple threads to exchange messages efficiently.

Redis presents a single point of failure and lacks fault tolerance. It would be beneficial if high availability features were available in the noncommercial version, similar to those offered by the commercial managed solutions from Redis Labs.

I have been working with Redis for over ten years.

If Redis is set up correctly, it requires no maintenance and can function smoothly for long periods without intervention. Memory calculations should be precise to avoid issues.

With approximately 500 microservices and environments scaling up to 1,000 customers, Redis accommodates a range of scales. Proper memory allocation allows for seamless operation.

We have not utilized customer support for Redis.

In comparison to other caching solutions like Memcached and Aerospike, Redis is easier to deploy and manage. Aerospike, while highly efficient, is more complex to set up.

The initial setup of Redis is very straightforward and user-friendly. Deploying Redis takes about thirty seconds, making it quick and efficient.

Implementation can be done in-house using AWS ElasticCache or Docker to run Redis on Kubernetes, depending on cost and environmental factors.

We use Kafka for inter-process communication, but Redis is used for thread intercommunication due to its PubSub capabilities.

I recommend Redis as it provides an easy-to-use caching solution with beneficial PubSub features.

It's excellent for startups or new projects with many components needing coordination. However, for more advanced messaging or larger data volumes, Redis might not be the best fit.

I rate Redis a nine out of ten.

I use Redis mostly to cache repeated data that is required. If I'm using a user wallet address, I don't need to call it all the time from the database. I do the cache using the solution.

The solution allows you to create a message of application publishing and messaging the application in other services. It helps a lot when I work with the microservice architecture.

I have been using Redis for four years.

I haven’t faced any stability issues with the solution.

I have never faced any issues with the solution’s scalability.

The solution is easy to set up and has very clear documentation.

To deploy Redis, you need knowledge about JavaScript, programming, and how data structures are stored. It takes around five to ten minutes to deploy the solution.

With Redis, I can create lists and key-value pairs. The solution also provides many features for storing data in cache. Storing data in memory using Redis is faster than using traditional databases like Postgres or MySQL.

If you are communicating with the services, you can use the solution's Pub/Sub capabilities to send messages, store data in cache, and share it with other microservices. The solution's data persistence model has greatly benefited our resilience, especially when storing any key-value pair.

You can install the solution on the local machine or cloud servers like AWS or Google Cloud. I would recommend Redis to other users.

Overall, I rate the solution a nine out of ten.

Sometimes, Redis is used as a cache and sometimes as the main database.

Redis is a simple, powerful, and fast solution.

Sometimes, we use Redis as a cluster, and the clusters can sometimes suffer some issues and bring some downtime to your application.

I have been using Redis for three years.

I rate Redis a seven or eight out of ten for stability.

In our team, around 20 to 25 engineers are using the solution.

I rate Redis a nine or ten out of ten for scalability.

The solution's technical support team was quite knowledgeable and fast.

We previously used other solutions like DynamoDB, Elasticsearch, and Postgres for different use cases. We switched to Redis because maintaining the cluster for Elasticsearch was very complex and a lot of work. Also, the other solutions were very, very expensive.

The solution’s initial setup is easy.

Since we're using the AWS self-managed version, Redis can be deployed very fast if you go through the console. If you do an infrastructure, its setup will take longer. But if you just want to play with it and set it up quickly, it can be done in 10 to 15 minutes or less.

The solution's pricing is good compared to other databases doing the same thing. It might be cheaper to use Redis in some cases and not in others. Redis is not an overpriced solution.

Redis is deployed on-cloud in our organization.

When it started, Redis had a very simple structure, but now it has a lot of powerful data structures. Users should investigate because they can use other things for their data structure. Redis has more new use cases. Users must consider that Redis is single-threaded, which might take a toll on them when they write to Redis. This might be an issue if you need very high throughput with writes.

Overall, I rate Redis a nine out of ten.