Best of Redis — November 2025

1. 1
   Article

   Simple Thread·27w

   I Love You, Redis, But I’m Leaving You for SolidQueue

   Rails 8 introduces SolidQueue, SolidCache, and SolidCable as PostgreSQL-based replacements for Redis in the default stack. SolidQueue leverages PostgreSQL's FOR UPDATE SKIP LOCKED feature to handle job queuing without lock contention, eliminating the operational complexity of maintaining Redis infrastructure. The article provides a complete migration guide from Sidekiq to SolidQueue, including setup instructions, recurring job configuration, and Mission Control monitoring. While Redis remains necessary for high-throughput applications processing thousands of jobs per second, SolidQueue handles 200-300 jobs/second and is sufficient for most Rails applications, as demonstrated by 37signals processing 20 million jobs daily on PostgreSQL.

   40
2. 2
   Article

   Platformatic·27w

   Next.js 16: Harness 'use cache' with Watt v3.18

   Watt 3.18 adds support for Next.js 16's new 'use cache' directive, enabling component-level distributed caching through Redis/Valkey integration. This solves a critical challenge for self-hosted Next.js deployments by providing shared cache across multiple application instances, eliminating cache inconsistencies that occur with default file-system caching. The update allows developers to explicitly cache individual React components and functions with surgical precision, while Watt handles the complexity of distributed cache configuration automatically. Note that enabling component caching disables traditional ISR caching due to Next.js 16 architectural limitations.

   12
3. 3
   Article

   Flipkart Tech·28w

   When Good Locks Go Bad: Diagnosing a System Meltdown Under Load

   Engineers at Flipkart diagnosed a critical system failure during load testing for their Big Billion Days sale. Their Mirana service crashed under load due to excessive contention on a Redis distributed lock. Initial solutions using queuing failed because they violated the 'fail fast' principle. The team ultimately solved the problem by implementing an AtomicInteger-based semaphore to limit concurrent threads attempting lock acquisition. The key insight was optimizing for actual service performance (200-300ms per request) rather than downstream resource limits, reducing allowed concurrency from 128 to 5 threads per pod and achieving stable throughput of 90 QPS across 9 pods.

   10