January 2020 Summaries

Redis 6 introduces new features for better security and compliance, including support for SSL and Access Control Lists (ACLs). ACLs allow users to create multiple users with specific login passwords and permissions, making it easy to implement security and safety features such as restricting access to certain commands or keys. ACLs are a self-contained mechanism that can be opted-in when the server is started, without affecting performance, and are lightweight when enabled. The feature includes a default user named 'default' to make the transition smoother for existing codebases. Users can create basic users with all permissions, apply changes in a free-form way, add restrictions on keys, manage passwords by hash value, and generate secure passwords automatically. Redis 6 provides an easy introduction to ACLs, which require more time to master but are simple to learn.

Redis Day Seattle was a successful event that brought together around 300 developers, engineers, software architects, programmers, and business professionals for intensive training, thought leadership, and networking. The two-day conference covered topics such as Redis basics, streaming architectures, probabilistic data structures, RediSearch, and RedisTimeSeries. Attendees heard from representatives of various companies like Zulily, Twilio, MDmetrix, AWS, and others on how Redis helps solve their business problems. The event also highlighted the wide variety of businesses using Redis in their technology stack and demonstrated its capabilities beyond caching. Redis Day Seattle concluded with a networking happy hour where attendees shared their experiences and ideas related to Redis.

Mutualink's IT team modernized its Interoperable Response and Preparedness Platform (IRAPP) by adopting a microservices architecture, which enabled dozens of technology components to work seamlessly together. The company turned to Redis Enterprise as the central data store due to its ability to provide a flexible and efficient data layer with top performance, effortless scalability, and high availability. This allows Mutualink's platform to maintain consistently high performance and scale dynamically by adding servers or availability zones as collaboration volumes expand. With Redis Enterprise, Mutualink can handle a large number of concurrent data requests with sub-millisecond latency, while also ensuring high availability through Active-Active replication and conflict-free replicated datatypes (CRDT). The company now uses Redis as both a caching layer and primary data store, which enables faster deployment, reduced vendor sprawl, and increased efficiency.

The data layer plays a crucial role in microservices architecture, as each service manages its own private data store. Understanding this concept is essential for building scalable, manageably, and resilient applications. The authors of the new e-book "Redis Microservices for Dummies" discuss how Redis can be used to optimize the data layer and eliminate the need for a separate primary database. By using Redis, developers can simplify their architecture and reduce development time. The Redis Stars Podcast also provides insights into real-world use cases of Redis in microservices architectures.

This post discusses dealing with cache invalidation in computer science, particularly focusing on Redis' new feature for server-assisted client-side caching (RSACSC) in version 6. The author presents a real-world test of RSACSC using Python and highlights the benefits of this mechanism, such as reduced latency and improved efficiency. Additionally, the post covers the impact of cache misses on performance and how to handle them effectively.

In today's distributed systems, many database systems were developed with a single database serving the entire enterprise, whereas Redis evolved differently, designed to store active data that will change often, with an indefinite structure and minimal resources required for massive throughput. A microservices architecture is characterized by individual services designed to fit specific use cases, each concerning themselves only with input/output and private data, allowing Redis databases to back a wide range of different microservices. Each service must perform as fast as possible due to inter-service communication overhead, making state maintenance crucial and isolating service data from other data layers for uncoupled scaling and cross-service contention. Services are designed to fill single roles in business processes, with non-relational state well-suited to NoSQL data models like Redis. Once built, services communicate through private HTTP endpoints or log-like structures, such as Redis Streams, allowing for asynchronous event announcements and bidirectional communication. Even without using Redis for storage or communication, it can play a vital role by caching frequently accessed data, preventing unneeded API calls from impacting performance.

Redis Streams is a data type that represents a log, allowing new information and messages to be added in an append-only mode. It enables building "Kafka-like" applications with features like consumer groups for distributed message consumption, making it easy to scale and create highly available systems. Redis Streams differs from Redis Pub/Sub as they aim to accomplish different things. To learn how to use Redis Streams and Java, one can build a sample application using the redis-streams-101-java GitHub repository. The Lettuce Java client is recommended for working with Redis Streams. By creating a producer and consumer applications, messages can be posted to a stream, and consumed using a consumer group. This basic example demonstrates how to use Lettuce to publish messages to a stream, create a consumer group, and consume messages using the consumer group.