Beyond Caching: How Redis Powers Real‑World Storage and Services

Most databases interact with disk and become slow under high concurrency. To mitigate this, many systems add a cache layer. Redis, with its excellent performance and rich data structures, has become the de facto standard for distributed caching.

However, Redis is not limited to caching.

Its rich data structures and persistence (RDB) allow it to be used as a primary database, supporting many internet companies, especially social, gaming, and live streaming services.

1. Redis Can Serve as a Storage Engine

Redis offers several clustering modes: master‑slave, sentinel, and cluster, satisfying high‑availability requirements. It also provides two persistence mechanisms: AOF and RDB, with RDB being the most commonly used.

Using the BGSAVE command, the master forks a new process to write a snapshot to disk. Because it lacks a WAL and checkpoint mechanism, it cannot guarantee real‑time backup; a sudden power loss may cause data loss.

Fortunately, Redis is an in‑memory database, and replication is fast. With proper cluster maintenance and memory allocation, its SLA remains high unless a data‑center outage occurs.

Data loss is possible, which is unacceptable for typical CRUD workloads, but many internet services can tolerate occasional loss because of their business characteristics.

Before fully embracing Redis, verify that your business meets the following conditions:

Most non‑core data has low reliability requirements; losing a few records is acceptable.

The workload primarily serves C‑end users with small, quickly addressable data sets and minimal range queries.

The cost of in‑memory data is acceptable.

Transactional operations are rarely needed.

These conditions are common in social, gaming, live‑streaming, and operational services, which can rely entirely on Redis.

2. Redis Application Scenarios

Redis’s flexible document model and rich data types support many use cases beyond caching.

2.1 Basic User Data Storage

Traditional relational tables are hard to evolve. Using Redis hash, you can store loosely structured user attributes as JSON values and retrieve only needed fields with HGET or HMGET.

>HSET user:199929 sex m
>HSET user:199929 age 22
>HGETALL user:199929
1) "sex"
2) "m"
3) "age"
4) "22"

This read‑heavy, write‑light pattern fits well with KV storage. Incremental updates are easy with HINCRBY.

2.2 Counters

Redis commands INCRBY and INCR allow fast increment/decrement of numeric values, useful for likes, follows, fan counts, comment totals, hotness scores, etc.

> INCRBY feed:e3kk38j4kl:like 1
> INCRBY feed:e3kk38j4kl:like 1
> GET feed:e3kk38j4kl:like
"2"

These operations execute in milliseconds and provide real‑time results.

2.3 Leaderboards

Redis zset (sorted set) implements top‑N leaderboards efficiently, even with tens of millions of entries, maintaining sub‑5 ms latency.

>ZADD sorted:xjjdog:2021-07 55 dog0
>ZADD sorted:xjjdog:2021-07 89 dog1
>ZADD sorted:xjjdog:2021-07 32 dog2
>ZCARD sorted:xjjdog:2021-07
3
>ZREVRANGE sorted:xjjdog:2021-07 0 -10 WITHSCORES
1) "dog1"
2) "89"
3) "dog0"
4) "55"
5) "dog2"
6) "32"

2.4 Friend Relationships

Redis set stores unique collections such as follow lists, fan lists, blacklists, and likes. Using ZADD and ZRANK you can add timestamps for relationship creation, and SINTER finds mutual friends.

2.5 Active User Counting

Bitmaps efficiently record boolean flags for massive user bases. Example commands:

>SETBIT online:2021-07-23 3876520333 1
>SETBIT online:2021-07-24 3876520333 1
>GETBIT online:2021-07-23 3876520333
1
>BITOP AND active online:2021-07-23 online:2021-07-24
>GETBIT active 3876520333
1

Large IDs should be pre‑processed to avoid excessive memory consumption.

2.6 Distributed Locks

Redis provides lightweight distributed locking via SET with NX and PX. Example Java implementation:

public String lock(String key, int timeOutSecond) {
    for (;;) {
        String stamp = String.valueOf(System.nanoTime());
        boolean exist = redisTemplate.opsForValue()
            .setIfAbsent(key, stamp, timeOutSecond, TimeUnit.SECONDS);
        if (exist) {
            return stamp;
        }
    }
}
public void unlock(String key, String stamp) {
    redisTemplate.execute(script, Arrays.asList(key), stamp);
}

The corresponding Lua script for safe release:

local stamp = ARGV[1]
local key = KEYS[1]
local current = redis.call("GET", key)
if stamp == current then
    redis.call("DEL", key)
    return "OK"
end

Redisson’s RedLock adds read/write lock semantics and handles multi‑instance failures.

2.7 Rate Limiting

Simple counters with INCR and EXPIRE implement basic rate limiting, though high traffic may cause burst spikes. Redisson’s RRateLimiter offers a smoother sliding‑window algorithm.

RRateLimiter limiter = redisson.getRateLimiter("xjjdogLimiter");
limiter.trySetRate(RateType.OVERALL, 5, 2, RateIntervalUnit.SECONDS);
limiter.acquire(3);

2.8 Message Queues

Redis lists act as simple queues using LPUSH and RPOP (or blocking BRPOP) for small‑scale flash‑sale scenarios. Pub/Sub provides broadcast messaging, and Redis 5.0’s stream type offers Kafka‑like topics and consumer groups.

2.9 Geolocation Services

Since Redis 3.2, the GEOADD command stores latitude/longitude pairs, enabling distance calculations, area queries, and nearby‑user features.

2.10 Extended Libraries

Redisson supplies dozens of distributed data structures (Set, Map, List, Queue, etc.) built on top of Redis, simplifying high‑concurrency application development.

3. Challenges of an All‑Redis Architecture

3.1 High‑Availability Challenges

Redis supports master‑slave, sentinel, and cluster modes. Cluster is popular but has drawbacks: virtual slots spread keys across 16 384 slots, making batch operations (e.g., MGET, HMSET) inefficient and increasing maintenance complexity. Master‑slave lacks automatic failover; sentinel adds monitoring overhead.

3.2 Hot‑Cold Data Separation

Redis stores all data in memory, which is costly for cold or historical data. Middleware can offload infrequently accessed data to slower stores while keeping hot data in Redis, preserving the same API for the application layer.

3.3 Functional Extensions

Modules like RediSearch add full‑text search. Data can be exported to big‑data platforms (e.g., Hadoop) via RDB parsing tools for analytics beyond Redis’s native capabilities.

4. Conclusion

Many internet services run primarily on Redis, especially social, gaming, and live‑streaming apps. Redis excels when data can be identified by a key, the dataset remains bounded, and occasional data loss is acceptable. Selecting the right tool for the right workload is essential for product success.