Redis — in-memory caching for websites and stores
Redis is the speed layer behind the websites, stores and marketplaces built on 4buildsite: it keeps in memory (RAM) exactly the data that must be served instantly — cached pages, sessions, carts, rate limits — and responds in under a millisecond. PostgreSQL stays the source of truth; Redis protects it under heavy traffic and makes the experience feel instant. It is included and managed by the platform, with zero configuration on your side.
What Redis is and why it is so fast
Redis (REmote DIctionary Server) is an open-source in-memory database: it keeps data in RAM rather than on disk, so it answers in under a millisecond. On 4buildsite we use it as an acceleration layer in front of PostgreSQL — for everything that must be served instantly: pages, sessions, carts and rate limits.
Unlike a disk, RAM is orders of magnitude faster, and Redis adds native data structures (string, hash, list, set, sorted set, stream) that allow complex operations directly in memory, with no round-trip to the main database. Command processing is single-threaded, so behaviour is predictable and free of race conditions.
- Typical latency under 1 ms and over 100,000 operations per second on a single node
- Native structures: hashes for sessions, sorted sets for leaderboards and rate limiting, streams for queues
- Single-threaded on commands → predictable behaviour, no complex locking
Caching: your pages and data, served instantly
The strategy is cache-aside: the first request reads from PostgreSQL and stores the result in Redis with a TTL (time to live); subsequent requests take it straight from memory. When you edit a page, the key is explicitly invalidated — we never serve stale data through a blind TTL.
For a presentation site or a store, this means product lists, menus, popular pages and content fragments are delivered in milliseconds even under heavy traffic, without overloading the database. At peaks (a campaign, Black Friday) Redis absorbs the repeated requests and keeps the site fast.
- Cache-aside with explicit invalidation — no stale data
- Caches page fragments and query results, not just whole pages
- Protects PostgreSQL at traffic peaks, cutting response times
Sessions, shopping cart and anti-abuse protection
User sessions and refresh tokens live in Redis: fast authentication, automatic expiry through TTL and instant revocation across all devices when someone logs out or changes their password.
The shopping cart in stores built on 4buildsite is kept in Redis for unauthenticated visitors — fast, with expiry, without bloating the main database. Redis also enforces rate limiting on contact forms and login, using sorted sets, stopping spam and brute-force attempts before they reach the database.
- Session store with automatic expiry and selective token revocation
- Persistent cart with TTL for anonymous visitors
- Rate limiting and anti-abuse on forms and authentication
Real-time and background job queues
Redis Pub/Sub and Streams power real-time updates: stock dropping live, an in-app notification, an order status changing — all without the visitor refreshing and without repeated polling that tires the server.
Heavy tasks (processing an image, generating an export, a sync) enter a Redis queue and are run by background workers, so the visitor gets an immediate response. A distributed locking mechanism guarantees a critical operation does not run twice.
- Pub/Sub and Streams for live events (stock, orders, notifications)
- Job queues for heavy processing run asynchronously
- Distributed locking for operations that must not run twice
Pros and cons
Pros
- Sub-1 ms responses: cached data is served virtually instantly
- Dramatically reduces PostgreSQL load under heavy traffic
- Native structures for sessions, cart, rate limiting and leaderboards
- Pub/Sub and Streams for real-time features, without polling
- Job queues for heavy processing, without blocking the visitor
- Included and managed by the platform — zero configuration for you
Limitations
- Data lives in RAM, which is pricier than disk → not for huge volumes of "cold" data
- It is a cache / auxiliary layer, not the source of truth — permanent data stays in PostgreSQL
- Persistence (RDB/AOF) reduces, but does not fully eliminate, the risk of losing the last seconds on a crash
- Requires a correct invalidation strategy, otherwise it can serve stale data
Quick verdict
Use Redis for everything that must be instant — caching, sessions, cart, rate limiting, real-time and job queues. Do not use it as the main data store; PostgreSQL stays for that. On 4buildsite you get both, wired up automatically: you do not have to choose or configure anything.
Specifications table
| Capability | Detail | Where it is used in the builder |
|---|---|---|
| Latency | < 1 ms (in-memory) | Pages and data served instantly |
| Throughput | > 100,000 ops/s per node | Heavy traffic without the database buckling |
| Data structures | string, hash, list, set, sorted set, stream | Sessions, cart, leaderboards, queues, rate limiting |
| Persistence | RDB snapshot + AOF log | Fast recovery after a restart |
| Expiry | Per-key TTL | Self-cleaning cart, sessions and cache |
| Real-time | Pub/Sub + Streams | Live stock, notifications, order status |
Redis (cache) vs. database only
| Criterion | With Redis | PostgreSQL only |
|---|---|---|
| Response time for repeated data | under 1 ms, from memory | tens of ms, a query on every request |
| Under heavy traffic | database protected, scales easily | database congests, risks timeouts |
| Cart and sessions | fast, with automatic expiry | tables that grow and load the database |
| Real-time | native Pub/Sub and Streams | repeated polling, expensive |
| Job queues | native, simple to use | improvised or missing solutions |
Frequently asked questions
What is Redis, in short?
An ultra-fast in-memory database used as a cache, session and real-time layer in front of the main database. It answers in under a millisecond and makes the site feel instant.
Why not use just PostgreSQL?
PostgreSQL is the source of truth (durable data), but Redis serves repeated data in under a millisecond and takes over the cart, sessions, rate limiting and real-time, protecting the database under heavy traffic. The two work together.
Do I lose data if Redis goes down?
Not your site content: permanent data is in PostgreSQL. Redis only holds cache and temporary data, and RDB/AOF persistence reduces losses. A Redis restart does not affect your published site.
Do I have to configure Redis myself?
No. It is included and managed by the 4buildsite platform; you get the speed and the real-time features without administering anything.
How does Redis help an online store?
A fast cart for visitors, cached product lists, live-updated stock and anti-abuse protection at checkout and on forms — all without loading the database.
Does Redis help SEO and Core Web Vitals?
Yes, indirectly: low response times improve TTFB and Core Web Vitals, signals that matter for Google as well as for user experience and AI engines.