Loading…
Topic
Redis
50 posts about Redis. Every summary links to the original.
- 50 posts
- 14 companies
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
How MakeMyTrip achieved millisecond personalization at scale with Databricks
MakeMyTrip needed sub-second personalization for “last-searched” hotels across its consumer and corporate travel businesses, serving millions of daily users. Spark Structured Streaming’s micro-batch mode consistently delivered one to two seconds, while adopting Flink would have added a second engine, duplicated logic and increased operational overhead. The team instead adopted Databricks Real-Time Mode (RTM), using continuous data flow, concurrent pipeline scheduling and streaming shuffle to process events with millisecond-level latency on Spark. Its unified pipeline merges B2C and B2B Kafka streams, enriches events with each user’s “Last N” hotels from Aerospike, and writes results to Redis for serving in under 50ms. After tuning partitions, backpressure and rate limits, the production deployment reduced P50 latency from approximately 1.23 seconds to 44ms, P99 latency from over one minute to about 500ms, and increased click-through rate by 7%.
How to Carry User Identity Across Federated Kubernetes and AI Platforms
Federated data and AI platforms let users move among portals, datasets, notebooks, and assistants across clusters, but single sign-on alone does not carry trusted identity across control-plane and data-plane boundaries. The post presents a central identity gateway that owns platform sessions through OIDC, a shared session store, stateless data-plane gateways, and an identity-validation API. Regional gateways validate sessions through /gateway/userinfo, enforce local policy, and inject standardized identity headers instead of forwarding raw tokens or independently managing refresh and logout. This separates session ownership from request enforcement, supports consistent logout, and lets assistants pass delegated user identity to backend tools without broad service credentials. At NVIDIA, the approach reduced repeated login events by 55% across internal developer platforms spanning Kubernetes clusters in AWS and OCI, while establishing a foundation for unified platform shells and AI assistants.
Bringing serverless functions closer to the speed of wire
Modal’s legacy I/O plane routed all function inputs and outputs through us-east servers, adding up to ~200ms of network latency for calls from other regions. The new geographically distributed I/O plane, available in four or more regions, reduces end-to-end function call latencies by roughly 80ms at p50. The redesign involved moving non-critical work to background async processing, minimizing shared storage interactions on the hot path, and rewriting the server layer in Go for better concurrency. The team evaluated Valkey but chose Redis 7.1 because engine CPU usage spiked aggressively on Redis 7.2 onwards during input queue load testing. Users can further optimize by selecting the nearest routing_region, keeping input and output payloads under 2MiB to avoid blob storage uploads, and batching small inputs to reduce network hops.
Online Learning for Cost-Efficient LLM Routing
Ramp describes an internal LLM gateway that processes trillions of tokens daily and uses dynamic failure-aware routing to reduce AI spend. It combines an EWMA of genuine provider-side failure rates with Thompson Sampling over a Normal-Inverse-Gamma posterior for the mean and variance of log-latency. For each request, the router estimates the probability of outright failure or missing the caller's deadline, incorporates model cost, and orders options while preserving caller-defined model preferences and fallbacks. In a reranker with a six-second deadline, the strategy reacted to Gemini 3.1 Flash Lite rate limiting by switching to GPT 5.4 Nano Flex, whose latency matched Standard at half the price. Larger experiments reported more than 25% cost savings without degradation, while a streaming-equivalent deployment for Ramp Inspect produced 30% savings.
How Uber Processes Early Chargeback Signals
Uber describes how it uses early chargeback signals, especially TC40 reports, to identify payment-fraud patterns before conventional chargebacks arrive. These notifications come from payment service providers through fraud reports and are ingested from external vendors via SFTP, third-party APIs, or webhooks, then validated, normalized, published to Apache Kafka, and stored in Apache Hive. A streaming pipeline maps signals to internal transactions and users, derives near-real-time features, and sends them to machine-learning models and a rule engine that determines risk actions. Redis TTL caching filters duplicate references, while Kafka propagates signals to downstream systems and Hive retains them for batch processing. Since launch, the project has processed more than 2 million additional signals, and TC40 signals arrive on average 4–5 days earlier than chargeback signals, although the source notes that TC40 data alone does not prevent chargebacks.
From hobby to real world: integrating the hard stuff with agents
The post documents building a production-oriented leaderboard for open-source Stripe Projects applications, where users submit projects, share links, and vote. Unlike an earlier transcription app, this project required authentication, multiple database tables, hosting, and controls limiting unauthenticated users to one vote per project. The agent initially selected Supabase for database and auth and Vercel for hosting, then added Upstash Redis after an in-memory rate limiter proved unsuitable for serverless enforcement. Supabase's two-emails-per-hour authentication limit prompted a human-directed migration to Clerk, after the agent proposed an unsuitable Twilio solution. The resulting MVP used five resources across four providers, took more than a day, and received separate security and performance audits before review.
From Rigid Rules to Empathetic Agents: Rebuilding Swiggy’s Order Cancellation Experience with LLMs
Swiggy rebuilt its “I Want To Cancel” (IWTC) support journey because a roughly 150K-line deterministic decision tree treated cancellation keywords alike, repeated canned deterrence, and could leave users stuck without handoff. The replacement is a stateful, multi-turn framework orchestrated with LangGraph: an intent layer identifies needs such as delay help, coupon support, direct cancellation, or human access, while live order signals and deterministic policy checks determine the next action. Full graph state is checkpointed in Redis by order- and session-level thread IDs, allowing conversations to resume across turns. Swiggy evaluated intent reliability using more than 100k historical chats and a pre-deployment suite of about 500 representative queries, then operated the system with reporting and alerts for behavioral and service metrics. The conclusion favors a hybrid design in which LLMs handle language while deterministic systems anchor truth and business decisions.
We replaced Redis with MySQL for inventory reservations—and it scaled
Shopify replaced its Redis-based inventory reservation system with MySQL to unify reservations with the inventory ledger and provide ACID coordination between payment and inventory updates. The new design stores one row per sellable unit in a bounded pool of up to 1,000 rows per item/location combination, uses MySQL 8's SKIP LOCKED to avoid waiting on locked units, and replenishes depleted pools. Composite primary keys reduced row locks, READ COMMITTED avoided gap locks that interfered with replenishment, and consistent lock ordering prevented deadlocks. The investigation found connection-pool usage elsewhere in checkout, rather than reservation query speed alone, was the immediate ceiling; cleanup removed 50% of primary-database reads and 33% of transactions, while configuration changes added headroom. Shopify validated the design in shadow mode, then rolled it out gradually with a Redis rollback path, meeting high-throughput targets during peak 2025 traffic.
Token-count-based Batching: Faster, Cheaper Embedding Inference for Queries
Serving embedding models for short search queries often suffers from poor GPU efficiency because traffic is spiky and memory-bound. Traditional time-window and request-count batching strategies lead to inconsistent GPU utilization, while tensor padding wastes compute on empty tokens. To resolve these bottlenecks, Voyage AI implemented token-count-based batching paired with padding removal in inference engines like vLLM. The architecture uses Redis with Lua scripts to atomically aggregate pending requests until reaching an optimal hardware saturation token threshold. Across production deployments, this approach achieved a 50% reduction in GPU inference latency with 3X fewer GPUs and improved throughput by up to 8×.
SignalR Scalability: Scaling Real-Time SignalR Applications on Heroku
Scaling a SignalR application beyond one server requires coordination because each server maintains its own connected-client list. The guide builds a .NET 9.0 chat application, adds the Microsoft.AspNetCore.SignalR.StackExchangeRedis package, and configures Redis as a backplane with a SignalRChat channel prefix and environment-specific connection settings. It deploys the application to Heroku, changes the dyno type to standard-1x, and runs three web dynos; without session affinity, WebSocket startup fails because the connection may be routed to a different dyno. Enabling Heroku’s http-session-affinity feature keeps requests on one dyno, after which both browsers establish stable WebSocket connections and exchange chat messages successfully across the scaled deployment.
Optimizing Stripe API performance in Lambda with caching strategies
The post addresses performance, cost, latency, and rate-limiting challenges that arise when applications make high-volume requests to Stripe's API from AWS Lambda. It presents a two-level cache using ElastiCache for Redis as the first layer and DynamoDB as the durable second layer, with Lambda coordinating cache reads, Stripe retrieval, and writes. On a miss, the function checks Redis, then DynamoDB, fetches the customer from Stripe if necessary, and stores the response in both layers with one-hour Redis and 24-hour DynamoDB TTLs. The DynamoDB design uses composite keys, a GSI for cache-type and timestamp queries, TTL cleanup, and environment-specific capacity settings; the post also discusses Redis connection pooling, Lambda sizing, capacity planning, cost control, monitoring, and webhook-based invalidation.
Evaluating performance impact of removing Redis-cache from a Scylla-backed service
A Rust service at Grab serves tens of thousands of peak QPS for batched count requests, using Scylla, Redis, and MySQL counter configurations. Its 15-minute cache-key truncation and five-minute TTL caused cache-hit declines and recurring Scylla QPS spikes at the end of each quarter-hour, when recent-data requests generated new keys. The experiment progressively disabled Redis, while a daily major compaction job was added to Scylla nodes; the service continued combining minutely, hourly, and daily tables for range calculations. With Redis fully decommissioned, Scylla cache hits rose from about 30% to 70% of reads, cache misses stayed about the same despite doubled traffic, peak CPU moved from roughly 50% to 52%, and overall service performance was maintained while eliminating a component responsible for about 25% of service cost.
Scaling Nextdoor’s Datastores: Part 5
Nextdoor addressed database and cache consistency issues caused by missed cache writes and concurrent read-fill operations in their look-aside architecture. While forward row versioning prevents out-of-order write inconsistencies, writer failures and race conditions during cache misses can leave stale data persisted in Redis. To resolve this, Nextdoor built a reconciliation pipeline that consumes PostgreSQL WAL replication logs with pg-bifrost, streams changes through Apache Kafka, and executes conditional deletions in Redis. The Go-based reconciler operates in two passes using a time wheel, running one pass in near real time and a second pass after a delay exceeding web request timeouts. Because conditional deletion evaluates row versions directly in the cache, the system processes change streams out of order and scales horizontally.
Scaling Nextdoor’s Datastores: Part 4
Look-aside caching systems can become inconsistent when concurrent database updates execute cache writes out of order, allowing stale data to overwrite newer modifications. To prevent these racing writes, Nextdoor introduced a unique, monotonic db_version column to Postgres tables using database triggers that initialize version numbers on insert and increment them on update. Application updates retrieve this new version inside a transaction block and attach it as a metadata header to serialized cache values. Redis then executes custom Lua scripts, specifically set_if_version and del_if_version, to perform atomic conditional updates that reject any incoming payload with a version lower than or equal to the stored version. This serializable check ensures that out-of-order writes are dropped and the cache remains strictly aligned with the latest database state.
Scaling Nextdoor’s Datastores: Part 3
Look-aside caching with object byte serialization can cause critical compatibility failures when application versions, dependencies, or database schemas change. Serialized cache entries bound to specific runtimes risk deserialization errors during deployments, triggering thundering herd queries against the underlying datastore. To resolve this, Nextdoor replaced runtime-bound serialization like Python pickle with MessagePack to serialize Django model objects. The team achieved forward compatibility by letting MessagePack ignore unrecognized new fields in older application code, while backward compatibility relies on mandatory default values for newly added model attributes. Nextdoor prepends a ten-byte header containing format metadata and version information before writing the serialized payload to cache stores.
Scaling Nextdoor’s Datastores: Part 1
Nextdoor relies on a Django backend connected to monolithic PostgreSQL databases and Redis look-aside caches. Migrating to distributed SQL datastores proved impractical because legacy business logic depends heavily on multi-table joins that could not be rewritten. Intermediate mitigations, including read replicas and data partitioning by severing foreign keys, extended infrastructure runways but left primary databases vulnerable to load bottlenecks. Furthermore, look-aside caching and replica usage introduced data staleness risks, atomicity losses across partitioned databases, and inconsistent cache-population behaviors. To address these limitations, Nextdoor initiated an architecture redesign focused on dynamic query routing to replicas, replica-driven cache hydration, time-bounded eventual consistency, and schema-resilient cache serialization.
The science of routing print orders
Canva's global print network requires selecting optimal suppliers to balance delivery times, packaging counts, and environmental emissions. To resolve these challenges before user checkout, the engineering team designed a modular routing architecture that decouples graph construction, decision logic, and path traversal. During graph traversal, the system generates action objects capturing forward paths and decision query results, which are compiled into timestamped routing logs in blob storage for asynchronous auditing. Utilizing preprocessed graph queries alongside ElastiCache, Redis, and database read replicas, the infrastructure sustains high-throughput evaluation without coupling cost logic to traversal code. As a result, print routing completes within an average of 50 milliseconds at the 99th percentile during peak usage while maintaining 99.999% data availability.
Creating reusable developer environments with Stripe Sandboxes
Setting up development machines with the correct tools, permissions, and dependencies can take weeks for new engineers, so the setup combines Stripe Sandboxes with development containers. Stripe Sandboxes provide isolated accounts with full Stripe API access for testing without real transactions, while sandbox settings remain independent and production customer, product, and transaction data is not copied. A C# example uses Bogus to generate ten fake products and Stripe.net’s ProductService to create them with metadata in the sandbox, and the text notes that SDKs can populate additional account data. The containerized workspace uses Docker development containers, a .NET 8 image, Redis via Docker Compose, environment variables, VS Code customizations, and a post-create script that installs Stripe CLI. Configuration files can then be checked into source control, giving team members an isolated and consistent workspace for exploring payment workflows without affecting live data.
Sliding window rate limits in distributed systems
Marketing communications across Grab's user base risked causing notification overload and consent revocations. To enforce personalized daily and weekly frequency caps across more than 270 million users, the team addressed segment membership storage and communication rate limiting. They adopted roaring bitmaps instead of Bloom filters to compactly store user segment data without hash collisions or costly rebuilds upon deletion. For frequency capping, they chose Amazon ElastiCache for Redis over DynamoDB, executing a sliding log rate limiting algorithm directly on the cluster using Lua scripts and sorted sets. Timestamps are stored as sorted set scores, and historical data is cleaned up via eviction ranges to prevent unbounded memory growth.
Vanilla with Candy Sprinkles
Vanilla with Candy Sprinkles presents a baseline full-stack Node.js application: a stateful visitor counter that increments across refreshes, tabs, browsers, and machines. The post starts with a dependency-free package.json and a 72-line server.js, then uses node-demo to generate variants with ECMAScript modules, EJS or Mustache templates, and Express. It adds SQLite3 or PostgreSQL for persistence, Tailwind CSS and TypeScript with a build step, and Drizzle, Knex, or Prisma as ORM options, noting differing language and build requirements. WebSockets provide real-time updates, htmx can handle client-side connection and DOM work, and Redis coordinates notifications across multiple servers; Fly.io deployment can scale the setup across eight instances in four regions. The concluding section points to further alternatives, including React, Angular, Lit, SolidJS, Svelte, Vue, esbuild, rollup, and other deployment targets, while inviting alternate implementations.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.