{"id":1150,"date":"2026-08-19T02:09:28","date_gmt":"2026-08-19T02:09:28","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1150"},"modified":"2026-08-19T02:09:29","modified_gmt":"2026-08-19T02:09:29","slug":"redis-tutorials-a-complete-fundamental-turorials","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/redis-tutorials-a-complete-fundamental-turorials\/","title":{"rendered":"Redis Tutorials: A Complete Fundamental Turorials"},"content":{"rendered":"\n

From Fundamentals to Production-Grade Caching, Sessions, Pub\/Sub, Counters, Locks and Failure Handling<\/h2>\n\n\n\n
\n\n\n\n

1. What is Redis?<\/h1>\n\n\n\n

Redis<\/strong> is a high-performance, primarily in-memory data store.<\/p>\n\n\n\n

The easiest mental model is:<\/p>\n\n\n\n

\n

Redis is a shared, extremely fast data-structure server that applications access over the network.<\/strong><\/p>\n<\/blockquote>\n\n\n\n

Instead of limiting you to simple key \u2192 value<\/code> pairs, Redis lets the value associated with a key be a String, Hash, List, Set, Sorted Set, Stream, and several other specialized structures<\/strong>. Redis officially describes itself as an in-memory data store that can be used for caching, messaging, streaming, document\/vector workloads and other use cases, with replication and optional disk persistence.<\/p>\n\n\n\n

A simple application might look like this:<\/p>\n\n\n\n

flowchart LR\n    U[User] --> A[Application]\n    A --> R[(Redis)]\n    A --> D[(Database)]\n\n    R -->|Fast cached data| A\n    D -->|Source of truth| A\n<\/code><\/pre>\n\n\n\n
Without Redis:<\/p>\n\n\n\n
Application\n     |\n     | SQL query\n     v\n Database\n     |\n     | 20-200 ms\n     v\n Application\n<\/code><\/pre>\n\n\n\n
With Redis:<\/p>\n\n\n\n
Application\n     |\n     | GET product:100\n     v\n   Redis\n     |\n     | Often sub-millisecond \/ low-millisecond\n     v\n Application\n<\/code><\/pre>\n\n\n\n
The exact latency depends on network, deployment, workload and payload size, but the important idea is:<\/p>\n\n\n\n
memory access is normally much faster than repeatedly performing expensive database queries or external API calls.<\/strong><\/p>\n\n\n\n
\n\n\n\n
2. Why Does Redis Exist?<\/h1>\n\n\n\n
Imagine an e-commerce site.<\/p>\n\n\n\n
Thousands of customers repeatedly request:<\/p>\n\n\n\n
Product ID: 100\nName: MacBook Pro\nPrice: \u20b9180000\nCategory: Laptop\nAvailability: In Stock\n<\/code><\/pre>\n\n\n\n
Without caching:<\/p>\n\n\n\n
Customer 1 \u2500\u2500\u2192 Database\nCustomer 2 \u2500\u2500\u2192 Database\nCustomer 3 \u2500\u2500\u2192 Database\nCustomer 4 \u2500\u2500\u2192 Database\nCustomer 5 \u2500\u2500\u2192 Database\n<\/code><\/pre>\n\n\n\n
The database repeatedly performs essentially the same work.<\/p>\n\n\n\n
With Redis:<\/p>\n\n\n\n
                 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\nCustomer \u2500\u2500\u2500\u2500\u2500\u2500\u2500>\u2502 Application  \u2502\n                 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                        |\n                    Check Redis\n                        |\n              \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25bc\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n              \u2502       Redis       \u2502\n              \u2502 product:100       \u2502\n              \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                        |\n                   Cache HIT\n                        |\n                        v\n                     Return\n<\/code><\/pre>\n\n\n\n
Only when Redis does not have the data does the application normally query the database.<\/p>\n\n\n\n
\n\n\n\n
3. Redis Is Not Just a Cache<\/h1>\n\n\n\n
This is one of the most important Redis concepts.<\/p>\n\n\n\n
Redis can be used for:<\/p>\n\n\n\n
Requirement<\/th>Redis capability<\/th><\/tr><\/thead>
Application caching<\/td>Strings \/ Hashes<\/td><\/tr>
User sessions<\/td>Strings \/ Hashes + TTL<\/td><\/tr>
Counters<\/td>INCR<\/code>, INCRBY<\/code><\/td><\/tr>
Leaderboards<\/td>Sorted Sets<\/td><\/tr>
Unique membership<\/td>Sets<\/td><\/tr>
Queues<\/td>Lists \/ Streams<\/td><\/tr>
Live notifications<\/td>Pub\/Sub<\/td><\/tr>
Event processing<\/td>Streams<\/td><\/tr>
Rate limiting<\/td>Counters + expiration<\/td><\/tr>
Temporary distributed coordination<\/td>SET NX<\/code><\/td><\/tr>
Geospatial lookup<\/td>Geospatial indexes<\/td><\/tr>
Unique visitor estimation<\/td>HyperLogLog<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Redis’ current documentation describes Redis as a data structure server<\/strong>, with native structures intended for use cases ranging from caching and queuing to event processing.<\/p>\n\n\n\n
\n\n\n\n
4. Redis Architecture \u2014 Simple Mental Model<\/h1>\n\n\n\n
Redis normally sits between your application and slower systems.<\/p>\n\n\n\n
flowchart TB\n\n    USER[Users]\n\n    LB[Load Balancer]\n\n    A1[Application Instance 1]\n    A2[Application Instance 2]\n    A3[Application Instance 3]\n\n    R[(Redis)]\n\n    DB[(Primary Database)]\n\n    USER --> LB\n\n    LB --> A1\n    LB --> A2\n    LB --> A3\n\n    A1 --> R\n    A2 --> R\n    A3 --> R\n\n    A1 --> DB\n    A2 --> DB\n    A3 --> DB\n<\/code><\/pre>\n\n\n\n
Redis provides something extremely useful here:<\/p>\n\n\n\n
shared fast state.<\/strong><\/p>\n\n\n\n
Application instances do not need to keep everything inside their own memory.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
App-1 local memory \u2260 App-2 local memory\n<\/code><\/pre>\n\n\n\n
But:<\/p>\n\n\n\n
App-1 \u2500\u2500\u2510\nApp-2 \u2500\u2500\u253c\u2500\u2500> Same Redis\nApp-3 \u2500\u2500\u2518\n<\/code><\/pre>\n\n\n\n
All application instances can access the same session, counter, cached object or temporary lock.<\/p>\n\n\n\n
\n\n\n\n
5. Running Redis Locally<\/h1>\n\n\n\n
For learning, Docker is one of the easiest approaches. Redis’ official documentation provides Docker as one of its supported installation\/run options.<\/p>\n\n\n\n
Start Redis:<\/p>\n\n\n\n
docker run --name redis-lab \\\n  -p 6379:6379 \\\n  -d redis\n<\/code><\/pre>\n\n\n\n
Check the container:<\/p>\n\n\n\n
docker ps\n<\/code><\/pre>\n\n\n\n
Open Redis CLI:<\/p>\n\n\n\n
docker exec -it redis-lab redis-cli\n<\/code><\/pre>\n\n\n\n
Test Redis:<\/p>\n\n\n\n
PING\n<\/code><\/pre>\n\n\n\n
Result:<\/p>\n\n\n\n
PONG\n<\/code><\/pre>\n\n\n\n
Your Redis environment is ready.<\/p>\n\n\n\n
\n\n\n\n
6. Your First Redis Commands<\/h1>\n\n\n\n
Store something:<\/p>\n\n\n\n
SET name \"Rajesh\"\n<\/code><\/pre>\n\n\n\n
Read it:<\/p>\n\n\n\n
GET name\n<\/code><\/pre>\n\n\n\n
Result:<\/p>\n\n\n\n
\"Rajesh\"\n<\/code><\/pre>\n\n\n\n
Delete it:<\/p>\n\n\n\n
DEL name\n<\/code><\/pre>\n\n\n\n
Check whether it exists:<\/p>\n\n\n\n
EXISTS name\n<\/code><\/pre>\n\n\n\n
Expiration:<\/p>\n\n\n\n
SET verification_code \"928431\" EX 300\n<\/code><\/pre>\n\n\n\n
This means:<\/p>\n\n\n\n
Key   = verification_code\nValue = 928431\nTTL   = 300 seconds\n<\/code><\/pre>\n\n\n\n
Check remaining TTL:<\/p>\n\n\n\n
TTL verification_code\n<\/code><\/pre>\n\n\n\n
Redis supports expiration directly as part of SET<\/code> as well as through expiration commands such as EXPIRE<\/code>.<\/p>\n\n\n\n
\n\n\n\n
7. Keys Are Extremely Important<\/h1>\n\n\n\n
Redis applications commonly use readable hierarchical key names.<\/p>\n\n\n\n
Instead of:<\/p>\n\n\n\n
123\n<\/code><\/pre>\n\n\n\n
prefer:<\/p>\n\n\n\n
user:123\n<\/code><\/pre>\n\n\n\n
For a session:<\/p>\n\n\n\n
session:a81fc92\n<\/code><\/pre>\n\n\n\n
For a product:<\/p>\n\n\n\n
product:1001\n<\/code><\/pre>\n\n\n\n
For a shopping cart:<\/p>\n\n\n\n
cart:user:100\n<\/code><\/pre>\n\n\n\n
For a rate limiter:<\/p>\n\n\n\n
rate:user:100:2026-08-19T07:33\n<\/code><\/pre>\n\n\n\n
For a temporary lock:<\/p>\n\n\n\n
lock:order:5432\n<\/code><\/pre>\n\n\n\n
A useful convention is:<\/p>\n\n\n\n
<domain>:<entity>:<id>\n<\/code><\/pre>\n\n\n\n
For example:<\/p>\n\n\n\n
ecommerce:product:1001\necommerce:user:700\necommerce:session:abc123\n<\/code><\/pre>\n\n\n\n
Good key naming dramatically improves debugging and operations.<\/p>\n\n\n\n
\n\n\n\n
8. Redis Data Structures<\/h1>\n\n\n\n
Redis’ most important characteristic is that values are not all treated as identical blobs.<\/p>\n\n\n\n
The core structures you should understand first are:<\/p>\n\n\n\n
Structure<\/th>Think of it as<\/th>Common use case<\/th><\/tr><\/thead>
String<\/td>Single value<\/td>Cache, token, counter<\/td><\/tr>
Hash<\/td>Object \/ record<\/td>User, product, session<\/td><\/tr>
List<\/td>Ordered sequence<\/td>Queue<\/td><\/tr>
Set<\/td>Unique collection<\/td>Tags, membership<\/td><\/tr>
Sorted Set<\/td>Ranked collection<\/td>Leaderboard<\/td><\/tr>
Stream<\/td>Append-only event log<\/td>Event processing<\/td><\/tr>
Bitmap<\/td>Bits<\/td>Daily activity flags<\/td><\/tr>
HyperLogLog<\/td>Approximate unique count<\/td>Unique visitors<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Redis currently supports an even broader collection of native and specialized data types, but mastering these core structures gives you the foundation for most application workloads.<\/p>\n\n\n\n
\n\n\n\n
9. Redis String<\/h1>\n\n\n\n
A Redis String is the simplest structure.<\/p>\n\n\n\n
key \u2192 value\n<\/code><\/pre>\n\n\n\n
Example:<\/p>\n\n\n\n
SET product:100:name \"iPhone\"\nGET product:100:name\n<\/code><\/pre>\n\n\n\n
Strings are ideal for:<\/p>\n\n\n\n
    \n
  • cached JSON<\/li>\n\n\n\n
  • tokens<\/li>\n\n\n\n
  • OTPs<\/li>\n\n\n\n
  • feature flags<\/li>\n\n\n\n
  • configuration<\/li>\n\n\n\n
  • counters<\/li>\n<\/ul>\n\n\n\n
    Example JSON:<\/p>\n\n\n\n
    SET product:100 '{\"name\":\"iPhone\",\"price\":80000}'\n<\/code><\/pre>\n\n\n\n
    Retrieve:<\/p>\n\n\n\n
    GET product:100\n<\/code><\/pre>\n\n\n\n
    Output:<\/p>\n\n\n\n
    {\"name\":\"iPhone\",\"price\":80000}\n<\/code><\/pre>\n\n\n\n
    When should you use String?<\/h3>\n\n\n\n
    Use String when:<\/p>\n\n\n\n
    One key represents one logical value.\n<\/code><\/pre>\n\n\n\n
    For example:<\/p>\n\n\n\n
    user:100:last_login \u2192 \"2026-08-19\"\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    10. Redis Hash<\/h1>\n\n\n\n
    A Hash represents an object containing fields.<\/p>\n\n\n\n
    Think:<\/p>\n\n\n\n
    user:100\n   |\n   +-- name  = Asha\n   +-- city  = Delhi\n   +-- age   = 30\n<\/code><\/pre>\n\n\n\n
    Commands:<\/p>\n\n\n\n
    HSET user:100 name \"Asha\" city \"Delhi\" age 30\n<\/code><\/pre>\n\n\n\n
    Read one field:<\/p>\n\n\n\n
    HGET user:100 name\n<\/code><\/pre>\n\n\n\n
    Read everything:<\/p>\n\n\n\n
    HGETALL user:100\n<\/code><\/pre>\n\n\n\n
    Update one field:<\/p>\n\n\n\n
    HSET user:100 city \"Mumbai\"\n<\/code><\/pre>\n\n\n\n
    A Redis Hash naturally represents many application records because Redis hashes are field-value collections similar to dictionaries or maps in programming languages.<\/p>\n\n\n\n
    Appropriate use cases<\/h3>\n\n\n\n
    User profile\nShopping cart\nSession information\nProduct metadata\nApplication configuration\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    11. Redis List<\/h1>\n\n\n\n
    A List is an ordered sequence.<\/p>\n\n\n\n
    Task A\nTask B\nTask C\nTask D\n<\/code><\/pre>\n\n\n\n
    Add:<\/p>\n\n\n\n
    LPUSH jobs \"send-email\"\n<\/code><\/pre>\n\n\n\n
    Add another:<\/p>\n\n\n\n
    LPUSH jobs \"generate-report\"\n<\/code><\/pre>\n\n\n\n
    Read:<\/p>\n\n\n\n
    LRANGE jobs 0 -1\n<\/code><\/pre>\n\n\n\n
    Redis lists preserve insertion ordering.<\/p>\n\n\n\n
    They can be useful for simple queue-like workloads.<\/p>\n\n\n\n
    However:<\/p>\n\n\n\n
    \n
    For sophisticated durable event processing, retries, consumer groups and replay, consider Redis Streams or a dedicated messaging platform rather than treating a List as a complete messaging system.<\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    12. Redis Set<\/h1>\n\n\n\n
    A Set contains unique values<\/strong>.<\/p>\n\n\n\n
    SADD product:100:tags electronics\nSADD product:100:tags mobile\nSADD product:100:tags apple\n<\/code><\/pre>\n\n\n\n
    Get members:<\/p>\n\n\n\n
    SMEMBERS product:100:tags\n<\/code><\/pre>\n\n\n\n
    Adding apple<\/code> again:<\/p>\n\n\n\n
    SADD product:100:tags apple\n<\/code><\/pre>\n\n\n\n
    does not create a duplicate.<\/p>\n\n\n\n
    Think:<\/p>\n\n\n\n
    Set = unique unordered collection\n<\/code><\/pre>\n\n\n\n
    Typical use cases:<\/p>\n\n\n\n
    User roles\nPermissions\nUnique tags\nOnline users\nGroup membership\nUnique categories\n<\/code><\/pre>\n\n\n\n
    Redis sets support constant-time add, remove and membership checks in typical cases.<\/p>\n\n\n\n
    \n\n\n\n
    13. Redis Sorted Set<\/h1>\n\n\n\n
    A Sorted Set contains unique members, but every member has a score<\/strong>.<\/p>\n\n\n\n
    Example leaderboard:<\/p>\n\n\n\n
    ZADD leaderboard 500 Alice\nZADD leaderboard 900 Bob\nZADD leaderboard 700 Charlie\n<\/code><\/pre>\n\n\n\n
    Read ranking:<\/p>\n\n\n\n
    ZRANGE leaderboard 0 -1 WITHSCORES\n<\/code><\/pre>\n\n\n\n
    Conceptually:<\/p>\n\n\n\n
    Bob       900\nCharlie   700\nAlice     500\n<\/code><\/pre>\n\n\n\n
    Use Sorted Sets for:<\/p>\n\n\n\n
    Leaderboards\nPriority systems\nRanking\nScores\nScheduling\nTop-N queries\n<\/code><\/pre>\n\n\n\n
    The difference is:<\/p>\n\n\n\n
    SET\nUnique values\n\nSORTED SET\nUnique values + score + ordering\n<\/code><\/pre>\n\n\n\n
    Redis defines sorted sets as unique strings maintained in order according to their associated score.<\/p>\n\n\n\n
    \n\n\n\n
    14. Redis Streams<\/h1>\n\n\n\n
    A Stream is fundamentally different.<\/p>\n\n\n\n
    Think:<\/p>\n\n\n\n
    Event 1\nEvent 2\nEvent 3\nEvent 4\n        \u2193\nnew events keep arriving\n<\/code><\/pre>\n\n\n\n
    Example:<\/p>\n\n\n\n
    XADD orders * order_id 1001 status created\n<\/code><\/pre>\n\n\n\n
    Another:<\/p>\n\n\n\n
    XADD orders * order_id 1002 status created\n<\/code><\/pre>\n\n\n\n
    Read:<\/p>\n\n\n\n
    XRANGE orders - +\n<\/code><\/pre>\n\n\n\n
    Redis describes Streams as an append-only log<\/strong> designed to record events in sequence and make them available for processing.<\/p>\n\n\n\n
    Good use cases include:<\/p>\n\n\n\n
    Order events\nAudit events\nTelemetry\nBackground processing\nConsumer groups\nDurable event workflows\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    15. Data Structure Decision Guide<\/h1>\n\n\n\n
    A very practical way to remember Redis structures is:<\/p>\n\n\n\n
    Need one value?\n        |\n      String\n\nNeed object fields?\n        |\n       Hash\n\nNeed ordered queue?\n        |\n       List\n\nNeed unique values?\n        |\n       Set\n\nNeed ranking?\n        |\n    Sorted Set\n\nNeed durable event log?\n        |\n      Stream\n<\/code><\/pre>\n\n\n\n
    Or:<\/p>\n\n\n\n
    Requirement<\/th>Choose<\/th><\/tr><\/thead>
    Cache product JSON<\/td>String<\/td><\/tr>
    Store session fields<\/td>Hash<\/td><\/tr>
    Simple task queue<\/td>List<\/td><\/tr>
    Unique users<\/td>Set<\/td><\/tr>
    Leaderboard<\/td>Sorted Set<\/td><\/tr>
    Durable event processing<\/td>Stream<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n
    16. What Is Caching?<\/h1>\n\n\n\n
    Caching means:<\/p>\n\n\n\n
    \n
    Store expensive-to-obtain data somewhere faster so the next request does not have to perform the expensive operation again.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
    Suppose:<\/p>\n\n\n\n
    Database query = 80 ms\nRedis GET      = much faster\n<\/code><\/pre>\n\n\n\n
    Instead of hitting the database 10,000 times for the same product:<\/p>\n\n\n\n
    Database\nDatabase\nDatabase\nDatabase\nDatabase\n<\/code><\/pre>\n\n\n\n
    we cache it:<\/p>\n\n\n\n
                 Redis\n           \/ \/ | \\ \\\n        request request\n             |\n        Database only\n        when necessary\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    17. Cache Hit and Cache Miss<\/h1>\n\n\n\n
    These two terms are fundamental.<\/p>\n\n\n\n
    Cache HIT<\/h2>\n\n\n\n
    Application asks Redis:<\/p>\n\n\n\n
    GET product:100\n<\/code><\/pre>\n\n\n\n
    Redis has it.<\/p>\n\n\n\n
    Application\n     |\n     v\n   Redis\n     |\n    HIT\n     |\n     v\n  Response\n<\/code><\/pre>\n\n\n\n
    No database query is needed.<\/p>\n\n\n\n
    \n\n\n\n
    Cache MISS<\/h2>\n\n\n\n
    Redis does not have it.<\/p>\n\n\n\n
    Application\n     |\n     v\n   Redis\n     |\n    MISS\n     |\n     v\n Database\n<\/code><\/pre>\n\n\n\n
    The application fetches the data and normally stores it in Redis.<\/p>\n\n\n\n
    \n\n\n\n
    18. Cache-Aside Pattern<\/h1>\n\n\n\n
    Cache-aside is probably the most important Redis caching pattern to learn.<\/p>\n\n\n\n
    It is also called:<\/p>\n\n\n\n
    Lazy Loading\n<\/code><\/pre>\n\n\n\n
    The application<\/strong> manages the cache.<\/p>\n\n\n\n
    The process is:<\/p>\n\n\n\n
    flowchart TD\n\n    A[Application receives request]\n\n    B{Data in Redis?}\n\n    C[Return cached data]\n\n    D[Query Database]\n\n    E[Store result in Redis]\n\n    F[Return result]\n\n    A --> B\n\n    B -->|Yes - HIT| C\n    B -->|No - MISS| D\n\n    D --> E\n    E --> F\n<\/code><\/pre>\n\n\n\n
    Algorithm:<\/p>\n\n\n\n
    1. Check Redis.\n2. If found \u2192 return it.\n3. If not found \u2192 query database.\n4. Put database result into Redis.\n5. Return result.\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    19. Cache-Aside Example<\/h1>\n\n\n\n
    Assume:<\/p>\n\n\n\n
    GET \/products\/100\n<\/code><\/pre>\n\n\n\n
    Pseudo-code:<\/p>\n\n\n\n
    def get_product(product_id):\n\n    key = f\"product:{product_id}\"\n\n    # Step 1: Check Redis\n    cached = redis.get(key)\n\n    if cached:\n        return cached\n\n    # Step 2: Cache miss\n    product = database.find_product(product_id)\n\n    # Step 3: Put data into Redis\n    redis.set(key, product, ex=300)\n\n    # Step 4: Return result\n    return product\n<\/code><\/pre>\n\n\n\n
    The first request looks like:<\/p>\n\n\n\n
    Client\n  |\n  v\nApplication\n  |\n  | GET product:100\n  v\nRedis\n  |\n MISS\n  |\n  v\nDatabase\n  |\n Product\n  |\n  v\nRedis SET + TTL\n  |\n  v\nClient\n<\/code><\/pre>\n\n\n\n
    Second request:<\/p>\n\n\n\n
    Client\n  |\n  v\nApplication\n  |\n  v\nRedis\n  |\n HIT\n  |\n  v\nClient\n<\/code><\/pre>\n\n\n\n
    No database access.<\/p>\n\n\n\n
    \n\n\n\n
    20. Why Cache-Aside Is So Popular<\/h1>\n\n\n\n
    It has several attractive properties.<\/p>\n\n\n\n
    The database remains the source of truth<\/strong>.<\/p>\n\n\n\n
    Redis contains copies of frequently accessed data.<\/p>\n\n\n\n
    If Redis loses a cache entry:<\/p>\n\n\n\n
    Not catastrophic\n<\/code><\/pre>\n\n\n\n
    because the application can recreate it from the database.<\/p>\n\n\n\n
    This architecture is extremely common:<\/p>\n\n\n\n
    Redis = optimization\nDatabase = authority\n<\/code><\/pre>\n\n\n\n
    That distinction is one of the safest Redis design principles.<\/p>\n\n\n\n
    \n\n\n\n
    21. The Problem With Cache-Aside<\/h1>\n\n\n\n
    Caching introduces another copy of the data.<\/p>\n\n\n\n
    Suppose:<\/p>\n\n\n\n
    Database:<\/p>\n\n\n\n
    product:100.price = \u20b980,000\n<\/code><\/pre>\n\n\n\n
    Redis:<\/p>\n\n\n\n
    product:100.price = \u20b980,000\n<\/code><\/pre>\n\n\n\n
    Someone updates the database:<\/p>\n\n\n\n
    product:100.price = \u20b975,000\n<\/code><\/pre>\n\n\n\n
    But Redis still contains:<\/p>\n\n\n\n
    \u20b980,000\n<\/code><\/pre>\n\n\n\n
    You now have:<\/p>\n\n\n\n
    Stale Data<\/h1>\n\n\n\n
    That leads directly to one of the hardest caching problems:<\/p>\n\n\n\n
    Cache Invalidation<\/h1>\n\n\n\n
    \n\n\n\n
    22. Read-Through \/ Cache-Through<\/h1>\n\n\n\n
    In cache-aside:<\/p>\n\n\n\n
    Application knows how to load the cache.\n<\/code><\/pre>\n\n\n\n
    Conceptually:<\/p>\n\n\n\n
    Application\n   |\n   +---- Redis\n   |\n   +---- Database\n<\/code><\/pre>\n\n\n\n
    In a read-through\/cache-through abstraction<\/strong>, the application interacts with a cache layer:<\/p>\n\n\n\n
    Application\n     |\n     v\nCache Layer\n     |\n     +---- Redis\n     |\n     +---- Database loader\n<\/code><\/pre>\n\n\n\n
    When data is missing:<\/p>\n\n\n\n
    Cache Layer\n     |\n     v\nDatabase\n     |\n     v\nRedis\n<\/code><\/pre>\n\n\n\n
    The difference is primarily who owns the loading logic<\/strong>.<\/p>\n\n\n\n
    Redis commands themselves do not magically execute your SQL query because GET<\/code> misses. A framework, library or application layer implements that behavior.<\/p>\n\n\n\n
    \n\n\n\n
    23. Write-Through Caching<\/h1>\n\n\n\n
    Write-through means:<\/p>\n\n\n\n
    \n
    When the application writes data, the authoritative store and cache are updated as part of the write path.<\/p>\n<\/blockquote>\n\n\n\n
    Conceptually:<\/p>\n\n\n\n
    flowchart LR\n\n    A[Application]\n    C[Cache Layer]\n    R[(Redis)]\n    D[(Database)]\n\n    A -->|Write| C\n    C --> D\n    C --> R\n<\/code><\/pre>\n\n\n\n
    Example:<\/p>\n\n\n\n
    UPDATE product price\n        |\n        +----> Database = \u20b975,000\n        |\n        +----> Redis    = \u20b975,000\n<\/code><\/pre>\n\n\n\n
    The goal is to keep Redis warm and synchronized.<\/p>\n\n\n\n
    \n\n\n\n
    24. Write-Behind \/ Write-Back<\/h1>\n\n\n\n
    Another architecture sometimes discussed alongside these patterns is write-behind<\/strong>.<\/p>\n\n\n\n
    Application\n     |\n     v\n   Cache\n     |\n     | asynchronous\n     v\n Database\n<\/code><\/pre>\n\n\n\n
    The application may return before the database has been updated.<\/p>\n\n\n\n
    Advantage:<\/p>\n\n\n\n
    Very fast writes\n<\/code><\/pre>\n\n\n\n
    Risk:<\/p>\n\n\n\n
    Cache failure before persistence\n      \u2193\nPotential data loss\n<\/code><\/pre>\n\n\n\n
    This pattern requires much more careful durability design.<\/p>\n\n\n\n
    For ordinary application caching, cache-aside or well-designed write-through strategies are usually easier to reason about.<\/p>\n\n\n\n
    \n\n\n\n
    25. Cache Pattern Comparison<\/h1>\n\n\n\n
    Pattern<\/th>Read miss handled by<\/th>Writes handled by<\/th>Complexity<\/th>Typical use<\/th><\/tr><\/thead>
    Cache-aside<\/td>Application<\/td>Application\/DB<\/td>Low<\/td>Most applications<\/td><\/tr>
    Read-through<\/td>Cache abstraction<\/td>Application<\/td>Medium<\/td>Framework-managed caching<\/td><\/tr>
    Write-through<\/td>Cache abstraction<\/td>Cache + DB<\/td>Medium<\/td>Frequently read data<\/td><\/tr>
    Write-behind<\/td>Cache layer<\/td>Eventually DB<\/td>High<\/td>Specialized high-write workloads<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    The easiest pattern for most developers to start with is:<\/p>\n\n\n\n
    Cache-Aside<\/h1>\n\n\n\n
    \n\n\n\n
    26. TTL \u2014 Time To Live<\/h1>\n\n\n\n
    TTL determines how long a cached value remains valid.<\/p>\n\n\n\n
    Example:<\/p>\n\n\n\n
    SET product:100 \"...\" EX 300\n<\/code><\/pre>\n\n\n\n
    means:<\/p>\n\n\n\n
    Store this key for 300 seconds.\n<\/code><\/pre>\n\n\n\n
    After that:<\/p>\n\n\n\n
    Redis removes\/expires it.\n<\/code><\/pre>\n\n\n\n
    Check:<\/p>\n\n\n\n
    TTL product:100\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    27. Why TTL Is Important<\/h1>\n\n\n\n
    Without TTL:<\/p>\n\n\n\n
    Old cache entries\n      +\nUnused cache entries\n      +\nPotentially stale values\n      =\nMemory and correctness problems\n<\/code><\/pre>\n\n\n\n
    TTL provides a safety mechanism.<\/p>\n\n\n\n
    But:<\/p>\n\n\n\n
    \n
    TTL is not a replacement for proper invalidation when freshness matters.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    28. How Should You Select TTL?<\/h1>\n\n\n\n
    This question does not<\/strong> have one universal answer.<\/p>\n\n\n\n
    Do not think:<\/p>\n\n\n\n
    Redis TTL should always be 5 minutes.\n<\/code><\/pre>\n\n\n\n
    Instead ask:<\/p>\n\n\n\n
    How stale is this data allowed to become?\n<\/code><\/pre>\n\n\n\n
    Examples:<\/p>\n\n\n\n
    Data<\/th>Possible TTL<\/th><\/tr><\/thead>
    Country list<\/td>Hours \/ days<\/td><\/tr>
    Product description<\/td>Minutes \/ hours<\/td><\/tr>
    Product price<\/td>Shorter<\/td><\/tr>
    Inventory<\/td>Seconds or event-invalidated<\/td><\/tr>
    User profile<\/td>Minutes<\/td><\/tr>
    OTP<\/td>1\u201310 minutes<\/td><\/tr>
    Session<\/td>Based on session policy<\/td><\/tr>
    Static configuration<\/td>Long<\/td><\/tr>
    Real-time balance<\/td>Often avoid ordinary stale caching<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    The correct TTL comes primarily from the application’s freshness requirement<\/strong>, not from a Redis rule.<\/p>\n\n\n\n
    \n\n\n\n
    29. TTL Decision Model<\/h1>\n\n\n\n
    Consider four things:<\/p>\n\n\n\n
    Business freshness requirement\n          +\nHow frequently data changes\n          +\nCost of rebuilding cache\n          +\nTraffic \/ database capacity\n          =\nTTL decision\n<\/code><\/pre>\n\n\n\n
    For example:<\/p>\n\n\n\n
    Product Description\nchanges once per week\n\u2193\nTTL could be relatively long\n<\/code><\/pre>\n\n\n\n
    But:<\/p>\n\n\n\n
    Flash Sale Price\nchanges frequently\n\u2193\nLong TTL could be dangerous\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    30. TTL Jitter<\/h1>\n\n\n\n
    Imagine 100,000 product keys are populated at 10:00 AM with:<\/p>\n\n\n\n
    TTL = exactly 3600 seconds\n<\/code><\/pre>\n\n\n\n
    At 11:00 AM:<\/p>\n\n\n\n
    100,000 keys expire\n<\/code><\/pre>\n\n\n\n
    Suddenly:<\/p>\n\n\n\n
    100,000 requests \u2192 database\n<\/code><\/pre>\n\n\n\n
    This can cause a cache stampede.<\/p>\n\n\n\n
    Instead of identical TTLs:<\/p>\n\n\n\n
    3600\n3600\n3600\n3600\n3600\n<\/code><\/pre>\n\n\n\n
    use jitter:<\/p>\n\n\n\n
    3412\n3678\n3554\n3721\n3498\n<\/code><\/pre>\n\n\n\n
    For example:<\/p>\n\n\n\n
    ttl = 3600 + random.randint(-300, 300)\n<\/code><\/pre>\n\n\n\n
    Now expiration is distributed across time.<\/p>\n\n\n\n
    \n\n\n\n
    31. Absolute vs Sliding Expiration<\/h1>\n\n\n\n
    Absolute expiration<\/h2>\n\n\n\n
    Session:<\/p>\n\n\n\n
    Created 09:00\nExpires 10:00\n<\/code><\/pre>\n\n\n\n
    Usage does not extend it.<\/p>\n\n\n\n
    \n\n\n\n
    Sliding expiration<\/h2>\n\n\n\n
    Every valid activity refreshes expiration.<\/p>\n\n\n\n
    09:00 login\n      |\n09:20 activity \u2192 expiry becomes 10:20\n      |\n09:50 activity \u2192 expiry becomes 10:50\n<\/code><\/pre>\n\n\n\n
    Sliding expiration is common for user sessions.<\/p>\n\n\n\n
    However, security-sensitive applications may combine:<\/p>\n\n\n\n
    Idle timeout\n+\nMaximum absolute lifetime\n<\/code><\/pre>\n\n\n\n
    so a session cannot live forever.<\/p>\n\n\n\n
    \n\n\n\n
    32. Cache Invalidation<\/h1>\n\n\n\n
    Cache invalidation means:<\/p>\n\n\n\n
    \n
    Removing or replacing cached data when the underlying authoritative data changes.<\/p>\n<\/blockquote>\n\n\n\n
    Example:<\/p>\n\n\n\n
    Database\nproduct:100\nprice = \u20b980,000\n\nRedis\nproduct:100\nprice = \u20b980,000\n<\/code><\/pre>\n\n\n\n
    Price changes:<\/p>\n\n\n\n
    Database = \u20b975,000\n<\/code><\/pre>\n\n\n\n
    What should happen to Redis?<\/p>\n\n\n\n
    You need an invalidation strategy.<\/p>\n\n\n\n
    \n\n\n\n
    33. Strategy 1 \u2014 TTL-Only Invalidation<\/h1>\n\n\n\n
    Update DB:<\/p>\n\n\n\n
    Database = \u20b975,000\n<\/code><\/pre>\n\n\n\n
    Do nothing to Redis.<\/p>\n\n\n\n
    Wait until:<\/p>\n\n\n\n
    TTL expires\n<\/code><\/pre>\n\n\n\n
    Simple but potentially stale.<\/p>\n\n\n\n
    Use when:<\/p>\n\n\n\n
    Temporary staleness is acceptable.\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    34. Strategy 2 \u2014 Delete Cache After Database Update<\/h1>\n\n\n\n
    One of the most common strategies is:<\/p>\n\n\n\n
    1. Update Database\n2. Delete Redis key\n<\/code><\/pre>\n\n\n\n
    Example:<\/p>\n\n\n\n
    database.update_product(product)\n\nredis.delete(f\"product:{product.id}\")\n<\/code><\/pre>\n\n\n\n
    Next request:<\/p>\n\n\n\n
    Redis MISS\n    |\n    v\nDatabase\n    |\n    v\nFresh data\n    |\n    v\nRedis\n<\/code><\/pre>\n\n\n\n
    This is often safer than trying to independently reconstruct the exact cached representation during every write.<\/p>\n\n\n\n
    \n\n\n\n
    35. Strategy 3 \u2014 Update the Cache<\/h1>\n\n\n\n
    Another option:<\/p>\n\n\n\n
    UPDATE database\nUPDATE Redis\n<\/code><\/pre>\n\n\n\n
    Example:<\/p>\n\n\n\n
    database.update_product(product)\n\nredis.set(\n    f\"product:{product.id}\",\n    serialize(product),\n    ex=300\n)\n<\/code><\/pre>\n\n\n\n
    Advantage:<\/p>\n\n\n\n
    Cache remains warm.\n<\/code><\/pre>\n\n\n\n
    But application logic becomes more complicated because every write path must correctly update every relevant cache key.<\/p>\n\n\n\n
    \n\n\n\n
    36. Strategy 4 \u2014 Event-Driven Invalidation<\/h1>\n\n\n\n
    Large systems often use events.<\/p>\n\n\n\n
    Example:<\/p>\n\n\n\n
    Product Service\n      |\n      | ProductUpdated\n      v\nMessage Broker\n      |\n      v\nCache Invalidation Worker\n      |\n      v\nRedis DEL product:100\n<\/code><\/pre>\n\n\n\n
    This helps when many systems maintain derived caches.<\/p>\n\n\n\n
    \n\n\n\n
    37. Cache Invalidation Golden Rule<\/h1>\n\n\n\n
    Think of cached data as:<\/p>\n\n\n\n
    A derived copy<\/h1>\n\n\n\n
    not:<\/p>\n\n\n\n
    Automatically synchronized truth<\/h1>\n\n\n\n
    The system must answer:<\/p>\n\n\n\n
    Who updates the authoritative data?\n\nWho invalidates the cache?\n\nWhat happens if invalidation fails?\n\nHow stale may the cache become?\n<\/code><\/pre>\n\n\n\n
    TTL should frequently remain as a backup safety mechanism<\/strong> even if you actively invalidate keys.<\/p>\n\n\n\n
    \n\n\n\n
    38. Cache Stampede<\/h1>\n\n\n\n
    Now consider this very common failure.<\/p>\n\n\n\n
    A popular key:<\/p>\n\n\n\n
    homepage:recommendations\n<\/code><\/pre>\n\n\n\n
    receives:<\/p>\n\n\n\n
    20,000 requests\/second\n<\/code><\/pre>\n\n\n\n
    Redis contains it.<\/p>\n\n\n\n
    Everything works:<\/p>\n\n\n\n
    20,000 requests\n       |\n       v\n     Redis\n<\/code><\/pre>\n\n\n\n
    Then the key expires.<\/p>\n\n\n\n
    All requests see:<\/p>\n\n\n\n
    CACHE MISS\n<\/code><\/pre>\n\n\n\n
    And all query the database.<\/p>\n\n\n\n
    flowchart TD\n\n    K[Popular Redis key expires]\n\n    A1[Request 1]\n    A2[Request 2]\n    A3[Request 3]\n    A4[Request 10,000]\n\n    DB[(Database)]\n\n    K --> A1\n    K --> A2\n    K --> A3\n    K --> A4\n\n    A1 --> DB\n    A2 --> DB\n    A3 --> DB\n    A4 --> DB\n<\/code><\/pre>\n\n\n\n
    This is:<\/p>\n\n\n\n
    Cache Stampede<\/h1>\n\n\n\n
    also called:<\/p>\n\n\n\n
    Thundering Herd\nDogpile Effect\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    39. Why Cache Stampede Is Dangerous<\/h1>\n\n\n\n
    Normally:<\/p>\n\n\n\n
    Redis protects database.\n<\/code><\/pre>\n\n\n\n
    During a stampede:<\/p>\n\n\n\n
    Redis key expires\n        \u2193\nHuge number of cache misses\n        \u2193\nHuge database traffic\n        \u2193\nDatabase slows down\n        \u2193\nRequests take longer\n        \u2193\nEven more requests accumulate\n        \u2193\nPossible outage\n<\/code><\/pre>\n\n\n\n
    A cache that was intended to protect the database can therefore contribute to a sudden load spike if expiration is not designed carefully.<\/p>\n\n\n\n
    \n\n\n\n
    40. Stampede Protection \u2014 TTL Jitter<\/h1>\n\n\n\n
    First technique:<\/p>\n\n\n\n
    Do not expire thousands of related keys simultaneously.\n<\/code><\/pre>\n\n\n\n
    Instead:<\/p>\n\n\n\n
    baseTTL + random jitter\n<\/code><\/pre>\n\n\n\n
    Example:<\/p>\n\n\n\n
    ttl = 300 + random.randint(0, 60)\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    41. Stampede Protection \u2014 Single Refresher<\/h1>\n\n\n\n
    Instead of allowing every request to rebuild the cache:<\/p>\n\n\n\n
    Request A \u2192 obtains refresh lock\nRequest B \u2192 waits \/ serves stale\nRequest C \u2192 waits \/ serves stale\nRequest D \u2192 waits \/ serves stale\n<\/code><\/pre>\n\n\n\n
    Only:<\/p>\n\n\n\n
    Request A \u2192 Database\n<\/code><\/pre>\n\n\n\n
    Once refreshed:<\/p>\n\n\n\n
    Redis populated\n<\/code><\/pre>\n\n\n\n
    and other requests use the new value.<\/p>\n\n\n\n
    \n\n\n\n
    42. Stale-While-Revalidate<\/h1>\n\n\n\n
    Another powerful pattern:<\/p>\n\n\n\n
    Cache value exists\nbut soft TTL expired\n<\/code><\/pre>\n\n\n\n
    Instead of blocking the customer:<\/p>\n\n\n\n
    Return slightly stale value\n        +\nRefresh cache in background\n<\/code><\/pre>\n\n\n\n
    Conceptually:<\/p>\n\n\n\n
                        \u250c\u2500\u2500> Return stale value\nRequest \u2192 Redis \u2500\u2500\u2500\u2500\u2524\n                    \u2514\u2500\u2500> One worker refreshes\n                              |\n                              v\n                           Database\n<\/code><\/pre>\n\n\n\n
    This can be excellent for:<\/p>\n\n\n\n
    Homepages\nRecommendations\nContent\nCatalog information\n<\/code><\/pre>\n\n\n\n
    It may be unacceptable for:<\/p>\n\n\n\n
    Account balances\nCritical inventory guarantees\nSecurity permissions\n<\/code><\/pre>\n\n\n\n
    The business meaning of stale data matters.<\/p>\n\n\n\n
    \n\n\n\n
    43. Stale Data Risk<\/h1>\n\n\n\n
    Caching always creates the possibility of:<\/p>\n\n\n\n
    Database value \u2260 cached value\n<\/code><\/pre>\n\n\n\n
    Example:<\/p>\n\n\n\n
    Database inventory = 0\n\nRedis inventory = 5\n<\/code><\/pre>\n\n\n\n
    If Redis is blindly trusted:<\/p>\n\n\n\n
    Customer may purchase nonexistent stock.\n<\/code><\/pre>\n\n\n\n
    Therefore ask:<\/p>\n\n\n\n
    \n
    Is the data informational, or is it authoritative for a critical decision?<\/p>\n<\/blockquote>\n\n\n\n
    For critical decisions:<\/p>\n\n\n\n
    Redis can accelerate the process\n<\/code><\/pre>\n\n\n\n
    but the authoritative transactional system may still need to validate the final action.<\/p>\n\n\n\n
    \n\n\n\n
    44. Redis Pub\/Sub<\/h1>\n\n\n\n
    Pub\/Sub stands for:<\/p>\n\n\n\n
    Publish \/ Subscribe\n<\/code><\/pre>\n\n\n\n
    Components:<\/p>\n\n\n\n
    Publisher\nChannel\nSubscriber\n<\/code><\/pre>\n\n\n\n
    Example:<\/p>\n\n\n\n
    flowchart LR\n\n    P[Order Service]\n\n    C((order-events))\n\n    S1[Email Service]\n    S2[Notification Service]\n    S3[WebSocket Service]\n\n    P -->|Publish| C\n\n    C --> S1\n    C --> S2\n    C --> S3\n<\/code><\/pre>\n\n\n\n
    Redis uses commands such as:<\/p>\n\n\n\n
    SUBSCRIBE\nPUBLISH\nUNSUBSCRIBE\n<\/code><\/pre>\n\n\n\n
    for this model.<\/p>\n\n\n\n
    \n\n\n\n
    45. Redis Pub\/Sub Example<\/h1>\n\n\n\n
    Terminal 1:<\/p>\n\n\n\n
    SUBSCRIBE orders\n<\/code><\/pre>\n\n\n\n
    Terminal 2:<\/p>\n\n\n\n
    PUBLISH orders \"order-1001-created\"\n<\/code><\/pre>\n\n\n\n
    Subscriber receives the message.<\/p>\n\n\n\n
    Another example:<\/p>\n\n\n\n
    PUBLISH notifications \"user-100-logged-in\"\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    46. Pub\/Sub Is Not a Durable Queue<\/h1>\n\n\n\n
    This is critical.<\/p>\n\n\n\n
    Redis Pub\/Sub provides at-most-once delivery<\/strong>.<\/p>\n\n\n\n
    If a subscriber is disconnected when the message is published:<\/p>\n\n\n\n
    Message can be lost permanently.\n<\/code><\/pre>\n\n\n\n
    Redis explicitly documents this behavior and recommends Streams when stronger delivery guarantees and persistence are required.<\/p>\n\n\n\n
    Think:<\/p>\n\n\n\n
    Pub\/Sub\n\n\"Who is listening RIGHT NOW?\"\n<\/code><\/pre>\n\n\n\n
    versus:<\/p>\n\n\n\n
    Stream\n\n\"Record this event so consumers can process it.\"\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    47. Pub\/Sub vs Redis Streams<\/h1>\n\n\n\n
    Feature<\/th>Pub\/Sub<\/th>Streams<\/th><\/tr><\/thead>
    Persistent messages<\/td>No<\/td>Yes<\/td><\/tr>
    Offline consumer receives old message<\/td>No<\/td>Possible<\/td><\/tr>
    Consumer groups<\/td>No<\/td>Yes<\/td><\/tr>
    Replay<\/td>No<\/td>Yes<\/td><\/tr>
    Simple live broadcast<\/td>Excellent<\/td>Possible<\/td><\/tr>
    Durable processing<\/td>Poor fit<\/td>Good fit<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Use Pub\/Sub for:<\/p>\n\n\n\n
    Live notifications\nWebSocket fan-out\nLive dashboards\nCache invalidation notification\nEphemeral events\n<\/code><\/pre>\n\n\n\n
    Use Streams when:<\/p>\n\n\n\n
    Events must not simply disappear because a consumer disconnected.\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    48. Redis Pub\/Sub vs Kafka<\/h1>\n\n\n\n
    They solve overlapping but different problems.<\/p>\n\n\n\n
    Redis Pub\/Sub\n       \u2193\nFast ephemeral broadcast\n<\/code><\/pre>\n\n\n\n
    Kafka\n       \u2193\nDurable distributed event log\n<\/code><\/pre>\n\n\n\n
    A useful simplified comparison:<\/p>\n\n\n\n
    Requirement<\/th>Redis Pub\/Sub<\/th>Kafka<\/th><\/tr><\/thead>
    Live broadcast<\/td>Excellent<\/td>Yes<\/td><\/tr>
    Durable event log<\/td>No<\/td>Yes<\/td><\/tr>
    Replay<\/td>No<\/td>Yes<\/td><\/tr>
    Long retention<\/td>No<\/td>Yes<\/td><\/tr>
    Consumer offsets<\/td>No<\/td>Yes<\/td><\/tr>
    Very simple notifications<\/td>Excellent<\/td>Often overkill<\/td><\/tr>
    Enterprise event backbone<\/td>Usually no<\/td>Strong fit<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Do not automatically replace Kafka with Redis Pub\/Sub simply because both can transmit messages.<\/p>\n\n\n\n
    \n\n\n\n
    49. Redis for User Sessions<\/h1>\n\n\n\n
    Sessions are one of Redis’ classic use cases.<\/p>\n\n\n\n
    Imagine three application instances:<\/p>\n\n\n\n
    flowchart TB\n\n    U[User]\n\n    LB[Load Balancer]\n\n    A1[App 1]\n    A2[App 2]\n    A3[App 3]\n\n    R[(Redis Session Store)]\n\n    U --> LB\n\n    LB --> A1\n    LB --> A2\n    LB --> A3\n\n    A1 --> R\n    A2 --> R\n    A3 --> R\n<\/code><\/pre>\n\n\n\n
    Without shared session storage:<\/p>\n\n\n\n
    User logs in through App-1.\n\nNext request goes to App-2.\n\nApp-2:\n\"Who are you?\"\n<\/code><\/pre>\n\n\n\n
    With Redis:<\/p>\n\n\n\n
    App-1\nApp-2\nApp-3\n   |\n   v\nSame Redis session\n<\/code><\/pre>\n\n\n\n
    Any application instance can resolve the session.<\/p>\n\n\n\n
    \n\n\n\n
    50. Session Example<\/h1>\n\n\n\n
    Key:<\/p>\n\n\n\n
    session:f81d4fae\n<\/code><\/pre>\n\n\n\n
    Hash:<\/p>\n\n\n\n
    HSET session:f81d4fae \\\n    user_id 100 \\\n    role admin \\\n    authenticated true\n<\/code><\/pre>\n\n\n\n
    Expiration:<\/p>\n\n\n\n
    EXPIRE session:f81d4fae 1800\n<\/code><\/pre>\n\n\n\n
    Meaning:<\/p>\n\n\n\n
    Session expires after 30 minutes\n<\/code><\/pre>\n\n\n\n
    On logout:<\/p>\n\n\n\n
    DEL session:f81d4fae\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    51. Session Design Recommendations<\/h1>\n\n\n\n
    A session should normally have an expiration policy.<\/p>\n\n\n\n
    Avoid:<\/p>\n\n\n\n
    session:* with no expiration forever\n<\/code><\/pre>\n\n\n\n
    Also avoid placing unnecessary sensitive information directly into session objects.<\/p>\n\n\n\n
    Prefer:<\/p>\n\n\n\n
    Session ID\nUser ID\nAuthorization\/context information needed for session\nTimestamps\nMinimal metadata\n<\/code><\/pre>\n\n\n\n
    Keep the authoritative user\/account records elsewhere unless Redis has deliberately been designed as their primary system.<\/p>\n\n\n\n
    \n\n\n\n
    52. Distributed Counters<\/h1>\n\n\n\n
    Imagine ten application servers.<\/p>\n\n\n\n
    All must increment:<\/p>\n\n\n\n
    Number of API requests\n<\/code><\/pre>\n\n\n\n
    Local counters do not work:<\/p>\n\n\n\n
    App-1 = 100\nApp-2 = 200\nApp-3 = 170\n<\/code><\/pre>\n\n\n\n
    Redis provides shared counters:<\/p>\n\n\n\n
                Redis\n              |\n       api_requests = 470\n        \/     |      \\\n      App1   App2    App3\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    53. INCR<\/code><\/h1>\n\n\n\n
    Initialize:<\/p>\n\n\n\n
    SET pageviews 0\n<\/code><\/pre>\n\n\n\n
    Increment:<\/p>\n\n\n\n
    INCR pageviews\n<\/code><\/pre>\n\n\n\n
    Again:<\/p>\n\n\n\n
    INCR pageviews\n<\/code><\/pre>\n\n\n\n
    Result:<\/p>\n\n\n\n
    2\n<\/code><\/pre>\n\n\n\n
    Add 10:<\/p>\n\n\n\n
    INCRBY pageviews 10\n<\/code><\/pre>\n\n\n\n
    Result:<\/p>\n\n\n\n
    12\n<\/code><\/pre>\n\n\n\n
    Redis performs these counter operations atomically, which makes them extremely useful when many application instances modify the same counter.<\/p>\n\n\n\n
    \n\n\n\n
    54. Counter Use Cases<\/h1>\n\n\n\n
    Counters work well for:<\/p>\n\n\n\n
    Page views\nAPI calls\nDownloads\nLogin attempts\nRate limiting\nUsage quotas\nVotes\nTemporary metrics\n<\/code><\/pre>\n\n\n\n
    Example:<\/p>\n\n\n\n
    INCR article:500:views\n<\/code><\/pre>\n\n\n\n
    Ten application instances can safely increment the same Redis key.<\/p>\n\n\n\n
    \n\n\n\n
    55. Simple Rate Limiting<\/h1>\n\n\n\n
    Suppose:<\/p>\n\n\n\n
    Maximum = 100 requests\/minute\/user\n<\/code><\/pre>\n\n\n\n
    Key:<\/p>\n\n\n\n
    rate:user:100:202608190733\n<\/code><\/pre>\n\n\n\n
    First request:<\/p>\n\n\n\n
    SET rate:user:100:202608190733 1 EX 60 NX\n<\/code><\/pre>\n\n\n\n
    Subsequent requests:<\/p>\n\n\n\n
    INCR rate:user:100:202608190733\n<\/code><\/pre>\n\n\n\n
    If counter becomes:<\/p>\n\n\n\n
    101\n<\/code><\/pre>\n\n\n\n
    reject the request.<\/p>\n\n\n\n
    Concept:<\/p>\n\n\n\n
    Request\n   |\n   v\nINCR counter\n   |\n   +-- <= 100 \u2192 Allow\n   |\n   +-- > 100  \u2192 Reject\n<\/code><\/pre>\n\n\n\n
    Production-grade rate limiting may use Lua scripts, sorted sets or other algorithms such as sliding windows or token buckets depending on fairness and precision requirements.<\/p>\n\n\n\n
    \n\n\n\n
    56. Lightweight Distributed Locks<\/h1>\n\n\n\n
    Suppose two workers attempt:<\/p>\n\n\n\n
    Generate invoice 1001\n<\/code><\/pre>\n\n\n\n
    at the same time.<\/p>\n\n\n\n
    Without coordination:<\/p>\n\n\n\n
    Worker A \u2500\u2500> Generate\nWorker B \u2500\u2500> Generate\n\nPossible duplicate invoice\n<\/code><\/pre>\n\n\n\n
    A Redis lock can coordinate temporary access.<\/p>\n\n\n\n
    \n\n\n\n
    57. Basic Redis Lock<\/h1>\n\n\n\n
    Use:<\/p>\n\n\n\n
    SET lock:invoice:1001 abc123 NX EX 10\n<\/code><\/pre>\n\n\n\n
    Meaning:<\/p>\n\n\n\n
    SET     = create key\nNX      = only if key does not already exist\nEX 10   = automatically expire after 10 seconds\nabc123  = unique owner token\n<\/code><\/pre>\n\n\n\n
    Redis’ SET<\/code> command supports conditional creation with NX<\/code> and expiration with EX<\/code>\/PX<\/code>.<\/p>\n\n\n\n
    If successful:<\/p>\n\n\n\n
    Worker owns lock.\n<\/code><\/pre>\n\n\n\n
    If it fails:<\/p>\n\n\n\n
    Someone else owns lock.\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    58. Why Lock Expiration Is Essential<\/h1>\n\n\n\n
    Never create:<\/p>\n\n\n\n
    SET lock:invoice:1001 locked NX\n<\/code><\/pre>\n\n\n\n
    without thinking about failure.<\/p>\n\n\n\n
    Suppose:<\/p>\n\n\n\n
    Worker obtains lock\n      |\n      v\nWorker crashes\n<\/code><\/pre>\n\n\n\n
    Lock remains forever.<\/p>\n\n\n\n
    Now:<\/p>\n\n\n\n
    Nobody can process invoice 1001.\n<\/code><\/pre>\n\n\n\n
    Expiration creates a lease<\/strong>:<\/p>\n\n\n\n
    Lock eventually disappears.\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    59. Do Not Blindly Delete Somebody Else’s Lock<\/h1>\n\n\n\n
    Consider:<\/p>\n\n\n\n
    Worker A obtains lock for 10 sec.\n\nWorker A becomes slow.\n\nLock expires.\n\nWorker B obtains new lock.\n\nWorker A wakes up.\n\nWorker A executes DEL lock.\n<\/code><\/pre>\n\n\n\n
    Worker A has accidentally deleted:<\/p>\n\n\n\n
    Worker B's lock.\n<\/code><\/pre>\n\n\n\n
    That is why the value should contain a unique ownership token.<\/p>\n\n\n\n
    Example:<\/p>\n\n\n\n
    lock:invoice:1001\n         |\n         v\n550e8400-e29b-41d4-a716\n<\/code><\/pre>\n\n\n\n
    The owner should release the lock only if the stored token still belongs to it.<\/p>\n\n\n\n
    A classic safe release is an atomic compare-and-delete operation, often implemented with a small Lua script.<\/p>\n\n\n\n
    if redis.call(\"GET\", KEYS[1]) == ARGV[1] then\n    return redis.call(\"DEL\", KEYS[1])\nelse\n    return 0\nend\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    60. What Redis Locks Are Good For<\/h1>\n\n\n\n
    Good examples:<\/p>\n\n\n\n
    Prevent duplicate background refresh\nCoordinate cache rebuild\nPrevent duplicate scheduled job\nShort-lived idempotency coordination\nTemporary singleton work\n<\/code><\/pre>\n\n\n\n
    Be more cautious with:<\/p>\n\n\n\n
    Bank transfer correctness\nFinancial settlement\nStrict leader election\nIrreversible infrastructure control\nSafety-critical coordination\n<\/code><\/pre>\n\n\n\n
    A Redis lock is useful, but it is not automatically a substitute for a consensus system or database transaction.<\/p>\n\n\n\n
    For strict correctness, consider:<\/p>\n\n\n\n
    Database constraints\nTransactions\nIdempotency keys\nFencing tokens\nConsensus-based coordination\n<\/code><\/pre>\n\n\n\n
    depending on the problem.<\/p>\n\n\n\n
    \n\n\n\n
    61. Connection Pooling<\/h1>\n\n\n\n
    Applications should not normally do this for every request:<\/p>\n\n\n\n
    Request\n   |\nCreate TCP connection\n   |\nAuthenticate\n   |\nExecute GET\n   |\nClose connection\n<\/code><\/pre>\n\n\n\n
    Then repeat:<\/p>\n\n\n\n
    10,000 times\/second\n<\/code><\/pre>\n\n\n\n
    Connection establishment itself costs resources.<\/p>\n\n\n\n
    Instead, clients typically reuse connections.<\/p>\n\n\n\n
    flowchart LR\n\n    A[Application]\n\n    P[Connection Pool]\n\n    C1[Connection 1]\n    C2[Connection 2]\n    C3[Connection 3]\n\n    R[(Redis)]\n\n    A --> P\n\n    P --> C1\n    P --> C2\n    P --> C3\n\n    C1 --> R\n    C2 --> R\n    C3 --> R\n<\/code><\/pre>\n\n\n\n
    Redis’ current client documentation explicitly includes pooling\/multiplexing as a client concern, and documented clients include Python, Java, JavaScript, Go, .NET, PHP, Rust and others.<\/p>\n\n\n\n
    \n\n\n\n
    62. Connection Pool Mental Model<\/h1>\n\n\n\n
    Instead of:<\/p>\n\n\n\n
    Create\nUse\nDestroy\n\nCreate\nUse\nDestroy\n\nCreate\nUse\nDestroy\n<\/code><\/pre>\n\n\n\n
    do:<\/p>\n\n\n\n
    Create reusable connections\n       |\n       v\n      Pool\n       |\n       +---- request\n       +---- request\n       +---- request\n<\/code><\/pre>\n\n\n\n
    However, Redis clients differ.<\/p>\n\n\n\n
    Some primarily use:<\/p>\n\n\n\n
    Connection pools\n<\/code><\/pre>\n\n\n\n
    while others rely heavily on:<\/p>\n\n\n\n
    Connection multiplexing\n<\/code><\/pre>\n\n\n\n
    Therefore:<\/p>\n\n\n\n
    \n
    Follow the architecture of your chosen Redis client rather than blindly configuring an enormous pool.<\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    63. Connection Pool Parameters to Understand<\/h1>\n\n\n\n
    Typical settings include:<\/p>\n\n\n\n
    Maximum connections\nMinimum idle connections\nConnection timeout\nRead timeout\nWrite timeout\nPool wait timeout\nIdle timeout\nHealth checks\nTLS settings\nAuthentication\n<\/code><\/pre>\n\n\n\n
    Example conceptual configuration:<\/p>\n\n\n\n
    max_connections = 50\nconnect_timeout  = 1s\nread_timeout     = 500ms\npool_timeout     = 500ms\n<\/code><\/pre>\n\n\n\n
    Those are examples, not universal production values<\/strong>.<\/p>\n\n\n\n
    Pool sizing must consider:<\/p>\n\n\n\n
    Application concurrency\nNumber of application instances\nRedis connection capacity\nCommand latency\nPipeline\/multiplexing behavior\nTraffic pattern\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    64. Connection Pooling Golden Rule<\/h1>\n\n\n\n
    Do not calculate:<\/p>\n\n\n\n
    50 connections sounds good.\n<\/code><\/pre>\n\n\n\n
    Instead calculate total system load.<\/p>\n\n\n\n
    Suppose:<\/p>\n\n\n\n
    100 application pods\n\u00d7\n100 Redis connections\/pod\n=\n10,000 connections\n<\/code><\/pre>\n\n\n\n
    A seemingly small per-instance pool can become enormous across a cluster.<\/p>\n\n\n\n
    Always think:<\/p>\n\n\n\n
    Per-instance configuration \u00d7 number of instances<\/h1>\n\n\n\n
    \n\n\n\n
    65. Redis Failure Handling<\/h1>\n\n\n\n
    Eventually one of these will happen:<\/p>\n\n\n\n
    Redis unavailable\nNetwork problem\nTimeout\nConnection exhaustion\nFailover\nHigh latency\nMemory pressure\nApplication bug\n<\/code><\/pre>\n\n\n\n
    Your architecture must define what happens next.<\/p>\n\n\n\n
    This is often more important than the happy-path Redis code.<\/p>\n\n\n\n
    \n\n\n\n
    66. Example \u2014 Redis Cache Failure<\/h1>\n\n\n\n
    Normal:<\/p>\n\n\n\n
    Application\n     |\n     v\n   Redis\n     |\n    HIT\n<\/code><\/pre>\n\n\n\n
    Redis unavailable:<\/p>\n\n\n\n
    Application\n     |\n     X\n   Redis\n\n     |\n     v\n Database\n<\/code><\/pre>\n\n\n\n
    For ordinary cache data, a common strategy is:<\/p>\n\n\n\n
    \n
    Redis fails \u2192 bypass cache \u2192 query source of truth.<\/p>\n<\/blockquote>\n\n\n\n
    This is called:<\/p>\n\n\n\n
    Graceful degradation\n<\/code><\/pre>\n\n\n\n
    But there is an important danger.<\/p>\n\n\n\n
    \n\n\n\n
    67. Redis Failure Can Become Database Failure<\/h1>\n\n\n\n
    Imagine:<\/p>\n\n\n\n
    Redis handles 50,000 requests\/sec\n<\/code><\/pre>\n\n\n\n
    Redis fails.<\/p>\n\n\n\n
    Your fallback says:<\/p>\n\n\n\n
    Use database.\n<\/code><\/pre>\n\n\n\n
    Now:<\/p>\n\n\n\n
    50,000 requests\/sec \u2192 Database\n<\/code><\/pre>\n\n\n\n
    The database may support only:<\/p>\n\n\n\n
    5,000 queries\/sec.\n<\/code><\/pre>\n\n\n\n
    Result:<\/p>\n\n\n\n
    Redis outage\n    \u2193\nDatabase overload\n    \u2193\nApplication outage\n<\/code><\/pre>\n\n\n\n
    This is called a cascading failure<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    68. Protecting the Database During Redis Failure<\/h1>\n\n\n\n
    Useful mechanisms include:<\/p>\n\n\n\n
    Short Redis timeouts\nCircuit breakers\nRequest rate limiting\nBulkheads\nDatabase connection limits\nLoad shedding\nFallback data\nStale data\nRetry limits\nBackoff\nJitter\n<\/code><\/pre>\n\n\n\n
    Conceptually:<\/p>\n\n\n\n
    flowchart TD\n\n    A[Request]\n\n    B{Redis healthy?}\n\n    C[Redis]\n\n    D[Circuit Breaker]\n\n    E{DB capacity available?}\n\n    F[Database]\n\n    G[Fallback \/ reject \/ stale response]\n\n    A --> B\n\n    B -->|Yes| C\n    B -->|No| D\n\n    D --> E\n\n    E -->|Yes| F\n    E -->|No| G\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    69. Never Use Unlimited Retries<\/h1>\n\n\n\n
    Bad:<\/p>\n\n\n\n
    Redis timeout\n    \u2193\nRetry\n    \u2193\nRetry\n    \u2193\nRetry\n    \u2193\nRetry forever\n<\/code><\/pre>\n\n\n\n
    During an outage every application instance begins retrying.<\/p>\n\n\n\n
    Now the recovering Redis server receives:<\/p>\n\n\n\n
    Massive retry storm.\n<\/code><\/pre>\n\n\n\n
    Better:<\/p>\n\n\n\n
    Short timeout\nBounded retries\nExponential backoff\nJitter\nCircuit breaker\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    70. Fail-Open vs Fail-Closed<\/h1>\n\n\n\n
    Redis failure behavior depends on what Redis is doing.<\/p>\n\n\n\n
    Consider a cache:<\/p>\n\n\n\n
    Redis unavailable\n\u2193\nQuery database\n<\/code><\/pre>\n\n\n\n
    Usually reasonable.<\/p>\n\n\n\n
    Now consider a security control:<\/p>\n\n\n\n
    Redis stores temporary account lockout information.\n<\/code><\/pre>\n\n\n\n
    Redis unavailable.<\/p>\n\n\n\n
    Should you:<\/p>\n\n\n\n
    Allow everyone?\n<\/code><\/pre>\n\n\n\n
    Maybe not.<\/p>\n\n\n\n
    This introduces:<\/p>\n\n\n\n
    Fail-open vs fail-closed<\/h1>\n\n\n\n
    Redis responsibility<\/th>Possible failure behavior<\/th><\/tr><\/thead>
    Product cache<\/td>Bypass Redis<\/td><\/tr>
    Recommendation cache<\/td>Serve stale\/default<\/td><\/tr>
    Session store<\/td>User may need to reauthenticate<\/td><\/tr>
    Rate limiter<\/td>Business\/security decision<\/td><\/tr>
    Lock<\/td>Do not blindly continue<\/td><\/tr>
    Feature flag<\/td>Use safe default<\/td><\/tr>
    Counters<\/td>Queue\/degrade depending on importance<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    There is no universal fallback rule.<\/p>\n\n\n\n
    The fallback must match the business consequence<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    71. Failure Handling Example<\/h1>\n\n\n\n
    A useful cache algorithm looks conceptually like:<\/p>\n\n\n\n
    def get_product(product_id):\n\n    try:\n        product = redis.get(product_id)\n\n        if product:\n            return product\n\n    except RedisError:\n        # Cache unavailable.\n        # Continue carefully to source of truth.\n        pass\n\n    product = database.get_product(product_id)\n\n    try:\n        redis.set(product_id, product, ex=300)\n    except RedisError:\n        # Do not fail user request just because cache population failed.\n        pass\n\n    return product\n<\/code><\/pre>\n\n\n\n
    Notice:<\/p>\n\n\n\n
    Redis failure\n\u2260\nAutomatically fail customer request\n<\/code><\/pre>\n\n\n\n
    because Redis is only a cache in this architecture.<\/p>\n\n\n\n
    \n\n\n\n
    72. Negative Caching<\/h1>\n\n\n\n
    Suppose someone repeatedly requests:<\/p>\n\n\n\n
    product:999999\n<\/code><\/pre>\n\n\n\n
    which does not exist.<\/p>\n\n\n\n
    Without negative caching:<\/p>\n\n\n\n
    Request\n   \u2193\nRedis MISS\n   \u2193\nDatabase\n   \u2193\nNot found\n<\/code><\/pre>\n\n\n\n
    Again:<\/p>\n\n\n\n
    Redis MISS\nDatabase\nNot found\n<\/code><\/pre>\n\n\n\n
    A malicious or accidental flood can repeatedly hit the database.<\/p>\n\n\n\n
    You can temporarily cache:<\/p>\n\n\n\n
    NOT_FOUND\n<\/code><\/pre>\n\n\n\n
    for a short TTL.<\/p>\n\n\n\n
    Example:<\/p>\n\n\n\n
    product:999999 \u2192 NOT_FOUND\nTTL = 30 seconds\n<\/code><\/pre>\n\n\n\n
    This is:<\/p>\n\n\n\n
    Negative caching<\/h1>\n\n\n\n
    But use short TTLs because the object might later be created.<\/p>\n\n\n\n
    \n\n\n\n
    73. Hot Keys<\/h1>\n\n\n\n
    Suppose nearly all traffic requests:<\/p>\n\n\n\n
    product:iphone-latest\n<\/code><\/pre>\n\n\n\n
    That single key becomes extremely hot.<\/p>\n\n\n\n
                     Redis\n                   |\n        product:iphone-latest\n         \/ \/ \/ \/ \/ \/ \/ \/ \/\n     millions of requests\n<\/code><\/pre>\n\n\n\n
    Even if Redis overall has enough capacity, extremely skewed key access can create localized load problems.<\/p>\n\n\n\n
    Monitor:<\/p>\n\n\n\n
    Traffic distribution\nCommand latency\nHot keys\nNetwork throughput\nCPU\n<\/code><\/pre>\n\n\n\n
    Caching architecture is not just about total key count.<\/p>\n\n\n\n
    \n\n\n\n
    74. Large Values<\/h1>\n\n\n\n
    Do not casually store enormous payloads under one key.<\/p>\n\n\n\n
    Example:<\/p>\n\n\n\n
    cache:everything\n    =\n500 MB JSON\n<\/code><\/pre>\n\n\n\n
    Problems include:<\/p>\n\n\n\n
    Network latency\nSerialization cost\nMemory pressure\nBlocking\/processing cost\nHuge invalidations\nPoor cache efficiency\n<\/code><\/pre>\n\n\n\n
    Prefer appropriately sized objects:<\/p>\n\n\n\n
    product:100\nproduct:101\nproduct:102\n<\/code><\/pre>\n\n\n\n
    when that matches your access pattern.<\/p>\n\n\n\n
    \n\n\n\n
    75. Redis Memory Is Not Infinite<\/h1>\n\n\n\n
    Redis is often memory-centric.<\/p>\n\n\n\n
    That means capacity planning matters.<\/p>\n\n\n\n
    Think:<\/p>\n\n\n\n
    Number of keys\n\u00d7\nAverage key size\n\u00d7\nAverage value size\n+\nRedis structure overhead\n+\nReplication\/persistence overhead\n+\nOperational headroom\n<\/code><\/pre>\n\n\n\n
    Do not estimate only:<\/p>\n\n\n\n
    My JSON files total 5 GB,\ntherefore I need exactly 5 GB RAM.\n<\/code><\/pre>\n\n\n\n
    Real Redis memory consumption includes metadata and internal representations.<\/p>\n\n\n\n
    \n\n\n\n
    76. TTL vs Eviction<\/h1>\n\n\n\n
    These are different concepts.<\/p>\n\n\n\n
    TTL<\/h2>\n\n\n\n
    You deliberately say:<\/p>\n\n\n\n
    This key should expire in 300 seconds.\n<\/code><\/pre>\n\n\n\n
    Eviction<\/h2>\n\n\n\n
    Redis is under configured memory pressure and removes keys according to the configured memory-management policy.<\/p>\n\n\n\n
    Therefore:<\/p>\n\n\n\n
    Expiration = data lifetime policy\n\nEviction = memory pressure policy\n<\/code><\/pre>\n\n\n\n
    Do not design correctness around the assumption that a cache entry will always survive until its TTL.<\/p>\n\n\n\n
    \n\n\n\n
    77. What Should Be Cached?<\/h1>\n\n\n\n
    Good caching candidates often have:<\/p>\n\n\n\n
    High read frequency\nExpensive computation\nExpensive DB query\nRepeated identical access\nTolerance for controlled staleness\nReasonable object size\n<\/code><\/pre>\n\n\n\n
    Examples:<\/p>\n\n\n\n
    Product catalog\nConfiguration\nUser profile summary\nSearch suggestions\nDashboard aggregates\nRecommendation results\nReference data\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    78. What Should Not Automatically Be Cached?<\/h1>\n\n\n\n
    Be cautious with:<\/p>\n\n\n\n
    Highly volatile authoritative financial data\nOne-time data rarely read again\nHuge objects\nData with extremely low cache hit rate\nData where stale values are dangerous\nQueries cheaper than cache management\nSensitive data without proper controls\n<\/code><\/pre>\n\n\n\n
    Caching has a cost:<\/p>\n\n\n\n
    Code complexity\nInvalidation logic\nMemory\nObservability\nFailure modes\nStaleness\nOperational burden\n<\/code><\/pre>\n\n\n\n
    A cache should solve a real performance or scalability problem.<\/p>\n\n\n\n
    \n\n\n\n
    79. Cache Hit Ratio<\/h1>\n\n\n\n
    One useful metric is:<\/p>\n\n\n\n
    Cache Hit Ratio\n=\nCache Hits\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nHits + Misses\n<\/code><\/pre>\n\n\n\n
    Example:<\/p>\n\n\n\n
    Hits   = 9,000\nMisses = 1,000\n<\/code><\/pre>\n\n\n\n
    Hit ratio:<\/p>\n\n\n\n
    9000 \/ 10000\n=\n90%\n<\/code><\/pre>\n\n\n\n
    A high hit ratio often indicates that Redis is successfully shielding the backend.<\/p>\n\n\n\n
    But high hit ratio alone does not prove success.<\/p>\n\n\n\n
    You should also ask:<\/p>\n\n\n\n
    Did application latency improve?\n\nDid database load decrease?\n\nIs the data fresh enough?\n\nWhat is Redis cost?\n\nAre hot keys forming?\n\nAre evictions increasing?\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    80. Important Redis Production Metrics<\/h1>\n\n\n\n
    Monitor at least the following categories.<\/p>\n\n\n\n
    Performance<\/h3>\n\n\n\n
    Command latency\np50\np95\np99\nOperations\/sec\nNetwork throughput\n<\/code><\/pre>\n\n\n\n
    Cache<\/h3>\n\n\n\n
    Hits\nMisses\nHit ratio\nEvictions\nExpired keys\n<\/code><\/pre>\n\n\n\n
    Memory<\/h3>\n\n\n\n
    Used memory\nMemory fragmentation\nmaxmemory utilization\nLarge keys\n<\/code><\/pre>\n\n\n\n
    Connections<\/h3>\n\n\n\n
    Connected clients\nConnection failures\nRejected connections\nPool exhaustion\n<\/code><\/pre>\n\n\n\n
    Availability<\/h3>\n\n\n\n
    Errors\nTimeouts\nFailovers\nReplication health\nReplication lag\n<\/code><\/pre>\n\n\n\n
    Backend impact<\/h3>\n\n\n\n
    Database QPS\nDatabase CPU\nDatabase connection utilization\nDatabase latency\n<\/code><\/pre>\n\n\n\n
    You need both Redis metrics and application\/backend metrics to understand whether caching is helping.<\/p>\n\n\n\n
    \n\n\n\n
    81. Complete Production Cache Request<\/h1>\n\n\n\n
    Now combine the concepts.<\/p>\n\n\n\n
    flowchart TD\n\n    U[Client Request]\n\n    A[Application]\n\n    R{Redis available?}\n\n    H{Cache Hit?}\n\n    C[Return Cached Value]\n\n    CB[Circuit Breaker \/ Protection]\n\n    DB[(Database)]\n\n    S[Store in Redis with TTL + Jitter]\n\n    RESP[Return Response]\n\n    FAIL[Fallback \/ Load Shed \/ Error]\n\n    U --> A\n\n    A --> R\n\n    R -->|Yes| H\n    R -->|No| CB\n\n    H -->|Yes| C\n\n    H -->|No| CB\n\n    CB -->|Backend capacity available| DB\n    CB -->|Backend protected| FAIL\n\n    DB --> S\n    S --> RESP\n<\/code><\/pre>\n\n\n\n
    This is much closer to a real production cache than simply:<\/p>\n\n\n\n
    redis.get()\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    82. Complete E-Commerce Example<\/h1>\n\n\n\n
    Let’s connect all the Redis use cases into one system.<\/p>\n\n\n\n
    flowchart TB\n\n    USER[Customers]\n\n    APP[Shopping Application]\n\n    REDIS[(Redis)]\n\n    DB[(SQL Database)]\n\n    PAYMENT[Payment Service]\n\n    EMAIL[Email Worker]\n\n    USER --> APP\n\n    APP --> REDIS\n    APP --> DB\n    APP --> PAYMENT\n\n    REDIS --> EMAIL\n<\/code><\/pre>\n\n\n\n
    Redis could provide:<\/p>\n\n\n\n
    product:*            \u2192 product cache\n\nsession:*            \u2192 sessions\n\ncart:*               \u2192 shopping carts\n\nrate:*               \u2192 rate limiting\n\nproduct:*:views      \u2192 counters\n\nleaderboard:*        \u2192 sorted sets\n\nlock:order:*         \u2192 lightweight coordination\n\nnotifications        \u2192 Pub\/Sub\n\norder-events         \u2192 Streams\n<\/code><\/pre>\n\n\n\n
    One Redis system therefore exposes several data-structure capabilities, but each use case has different durability and failure requirements.<\/p>\n\n\n\n
    \n\n\n\n
    83. Example Request \u2014 Product Page<\/h1>\n\n\n\n
    Customer requests:<\/p>\n\n\n\n
    GET \/products\/100\n<\/code><\/pre>\n\n\n\n
    Process:<\/p>\n\n\n\n
    1. Application receives request.\n\n2. GET product:100 from Redis.\n\n3. HIT?\n       YES\n       \u2193\n   Return product.\n\n4. MISS?\n       \u2193\n   Query database.\n\n5. Database returns product.\n\n6. Store:\n   product:100\n   TTL = base + jitter\n\n7. Return customer response.\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    84. Example Request \u2014 Add to Cart<\/h1>\n\n\n\n
    Redis Hash:<\/p>\n\n\n\n
    HSET cart:user:100 product:500 2\n<\/code><\/pre>\n\n\n\n
    Meaning:<\/p>\n\n\n\n
    User 100\nCart\n\nProduct 500\nQuantity 2\n<\/code><\/pre>\n\n\n\n
    Another:<\/p>\n\n\n\n
    HSET cart:user:100 product:600 1\n<\/code><\/pre>\n\n\n\n
    Now:<\/p>\n\n\n\n
    cart:user:100\n    |\n    +-- product:500 = 2\n    |\n    +-- product:600 = 1\n<\/code><\/pre>\n\n\n\n
    Add expiration if carts should disappear after inactivity.<\/p>\n\n\n\n
    \n\n\n\n
    85. Example Request \u2014 User Session<\/h1>\n\n\n\n
    Login:<\/p>\n\n\n\n
    HSET session:abc123 \\\n    user_id 100 \\\n    authenticated 1\n<\/code><\/pre>\n\n\n\n
    Set expiration:<\/p>\n\n\n\n
    EXPIRE session:abc123 1800\n<\/code><\/pre>\n\n\n\n
    Any application node can now resolve:<\/p>\n\n\n\n
    session:abc123\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    86. Example Request \u2014 Product Views<\/h1>\n\n\n\n
    Each product page:<\/p>\n\n\n\n
    INCR product:100:views\n<\/code><\/pre>\n\n\n\n
    Across:<\/p>\n\n\n\n
    App-1\nApp-2\nApp-3\nApp-4\n<\/code><\/pre>\n\n\n\n
    the counter is shared.<\/p>\n\n\n\n
    \n\n\n\n
    87. Example Request \u2014 Avoid Duplicate Order Processing<\/h1>\n\n\n\n
    Worker attempts:<\/p>\n\n\n\n
    SET lock:order:7001 unique-token NX EX 15\n<\/code><\/pre>\n\n\n\n
    Success:<\/p>\n\n\n\n
    Process order.\n<\/code><\/pre>\n\n\n\n
    Failure:<\/p>\n\n\n\n
    Another worker currently owns the lease.\n<\/code><\/pre>\n\n\n\n
    After work:<\/p>\n\n\n\n
    Atomic owner-token check\n+\ndelete lock\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    88. Example \u2014 Live Order Notification<\/h1>\n\n\n\n
    Publisher:<\/p>\n\n\n\n
    PUBLISH orders \"Order 7001 confirmed\"\n<\/code><\/pre>\n\n\n\n
    Subscribers:<\/p>\n\n\n\n
    WebSocket server\nNotification service\nDashboard\n<\/code><\/pre>\n\n\n\n
    receive it while connected.<\/p>\n\n\n\n
    If the business requirement becomes:<\/p>\n\n\n\n
    \"This message must never simply disappear.\"\n<\/code><\/pre>\n\n\n\n
    do not rely solely on Pub\/Sub.<\/p>\n\n\n\n
    Use something durable such as:<\/p>\n\n\n\n
    Redis Streams\nKafka\nanother durable broker\n<\/code><\/pre>\n\n\n\n
    depending on requirements.<\/p>\n\n\n\n
    \n\n\n\n
    89. When Redis Should NOT Be Used<\/h1>\n\n\n\n
    This is just as important as knowing when Redis should be used.<\/p>\n\n\n\n
    Do not automatically use Redis simply because:<\/p>\n\n\n\n
    Redis is fast.\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    90. Do Not Use Redis as a Replacement for Every Database<\/h1>\n\n\n\n
    Suppose you need:<\/p>\n\n\n\n
    SELECT customer.name,\n       SUM(order.amount)\nFROM customers\nJOIN orders ...\nJOIN invoices ...\nWHERE ...\nGROUP BY ...\n<\/code><\/pre>\n\n\n\n
    A relational database is designed for this type of workload.<\/p>\n\n\n\n
    Redis does not automatically replace:<\/p>\n\n\n\n
    PostgreSQL\nMySQL\nOracle\nSQL Server\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    91. Avoid Redis for Huge Cold Datasets<\/h1>\n\n\n\n
    Imagine:<\/p>\n\n\n\n
    20 TB archive\n<\/code><\/pre>\n\n\n\n
    that is accessed:<\/p>\n\n\n\n
    once every three months.\n<\/code><\/pre>\n\n\n\n
    Putting the entire dataset in expensive memory may provide little benefit.<\/p>\n\n\n\n
    A disk\/object-storage\/database architecture may be more appropriate.<\/p>\n\n\n\n
    \n\n\n\n
    92. Avoid Redis for Large Binary Objects<\/h1>\n\n\n\n
    Avoid treating Redis as:<\/p>\n\n\n\n
    Image repository\nVideo repository\nBackup repository\nISO repository\nMassive file store\n<\/code><\/pre>\n\n\n\n
    Instead use systems designed for large objects:<\/p>\n\n\n\n
    Amazon S3\nGoogle Cloud Storage\nAzure Blob Storage\nObject storage\/CDN\n<\/code><\/pre>\n\n\n\n
    Redis may cache metadata or small hot objects, but large binary storage is usually a poor fit.<\/p>\n\n\n\n
    \n\n\n\n
    93. Avoid Pub\/Sub for Durable Messaging<\/h1>\n\n\n\n
    Requirement:<\/p>\n\n\n\n
    PaymentCreated event MUST be processed.\n<\/code><\/pre>\n\n\n\n
    Subscriber crashes.<\/p>\n\n\n\n
    With Pub\/Sub:<\/p>\n\n\n\n
    Message may disappear.\n<\/code><\/pre>\n\n\n\n
    That violates the requirement.<\/p>\n\n\n\n
    Redis officially documents Pub\/Sub’s at-most-once semantics.<\/p>\n\n\n\n
    Use:<\/p>\n\n\n\n
    Redis Streams\nKafka\nRabbitMQ\nor another durable messaging architecture\n<\/code><\/pre>\n\n\n\n
    depending on the system’s requirements.<\/p>\n\n\n\n
    \n\n\n\n
    94. Do Not Use Redis Locks as Magical Distributed Transactions<\/h1>\n\n\n\n
    This:<\/p>\n\n\n\n
    SET lock:money-transfer NX EX 10\n<\/code><\/pre>\n\n\n\n
    does not suddenly provide:<\/p>\n\n\n\n
    Global transactional correctness\nDistributed consensus\nExactly-once execution\nFinancial settlement guarantees\n<\/code><\/pre>\n\n\n\n
    Distributed systems can experience:<\/p>\n\n\n\n
    Network delays\nProcess pauses\nClock\/time issues\nLease expiration\nFailover\nPartial failure\n<\/code><\/pre>\n\n\n\n
    Use Redis locking for problems whose correctness model fits a lease-based lock.<\/p>\n\n\n\n
    \n\n\n\n
    95. Avoid Redis When Caching Gives No Benefit<\/h1>\n\n\n\n
    Suppose:<\/p>\n\n\n\n
    Request A reads unique data once.\n\nRequest B reads different unique data once.\n\nRequest C reads different unique data once.\n<\/code><\/pre>\n\n\n\n
    Cache hit ratio approaches:<\/p>\n\n\n\n
    0%\n<\/code><\/pre>\n\n\n\n
    Now Redis adds:<\/p>\n\n\n\n
    Network call\nSerialization\nMemory\nInfrastructure cost\nOperational complexity\n<\/code><\/pre>\n\n\n\n
    without meaningfully reducing database work.<\/p>\n\n\n\n
    Do not cache merely because caching is fashionable.<\/p>\n\n\n\n
    \n\n\n\n
    96. Redis Decision Matrix<\/h1>\n\n\n\n
    Requirement<\/th>Redis?<\/th>Feature<\/th><\/tr><\/thead>
    Fast product cache<\/td>\u2705<\/td>String \/ Hash<\/td><\/tr>
    User sessions<\/td>\u2705<\/td>Hash\/String + TTL<\/td><\/tr>
    Distributed counter<\/td>\u2705<\/td>INCR<\/code><\/td><\/tr>
    Leaderboard<\/td>\u2705<\/td>Sorted Set<\/td><\/tr>
    Unique membership<\/td>\u2705<\/td>Set<\/td><\/tr>
    Live ephemeral notifications<\/td>\u2705<\/td>Pub\/Sub<\/td><\/tr>
    Durable event processing<\/td>\u2705<\/td>Streams<\/td><\/tr>
    Approximate unique visitor count<\/td>\u2705<\/td>HyperLogLog<\/td><\/tr>
    Temporary coordination<\/td>\u2705<\/td>SET NX EX<\/code><\/td><\/tr>
    Large relational joins<\/td>\u274c<\/td>Use relational DB<\/td><\/tr>
    Huge video archive<\/td>\u274c<\/td>Use object storage<\/td><\/tr>
    Durable Pub\/Sub-style event history<\/td>\u274c Pub\/Sub<\/td>Use Streams\/Kafka\/etc.<\/td><\/tr>
    Strong consensus<\/td>\u274c<\/td>Use appropriate coordination mechanism<\/td><\/tr>
    Low reuse \/ zero cache hits<\/td>Usually \u274c<\/td>Cache may add no value<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n
    97. Cache-Aside vs Write-Through Summary<\/h1>\n\n\n\n
    CACHE-ASIDE\n\nApplication\n   |\n   +--> Redis\n   |\n   +--> Database\n<\/code><\/pre>\n\n\n\n
    Application owns cache logic.<\/p>\n\n\n\n
    \n\n\n\n
    READ-THROUGH\n\nApplication\n   |\n   v\nCache abstraction\n   |\n   +--> Redis\n   |\n   +--> Database loader\n<\/code><\/pre>\n\n\n\n
    Cache abstraction owns loading logic.<\/p>\n\n\n\n
    \n\n\n\n
    WRITE-THROUGH\n\nApplication\n   |\n   v\nCache abstraction\n   |\n   +--> Cache\n   |\n   +--> Database\n<\/code><\/pre>\n\n\n\n
    Both are updated on the write path.<\/p>\n\n\n\n
    \n\n\n\n
    98. TTL Summary<\/h1>\n\n\n\n
    Never ask only:<\/p>\n\n\n\n
    What TTL should Redis use?\n<\/code><\/pre>\n\n\n\n
    Ask:<\/p>\n\n\n\n
    How stale may this data safely become?\n\nHow often does it change?\n\nHow expensive is reconstruction?\n\nWhat happens when thousands of keys expire?\n\nCan we actively invalidate it?\n<\/code><\/pre>\n\n\n\n
    Then choose:<\/p>\n\n\n\n
    TTL\n+\nJitter\n+\nInvalidation\n+\nStampede strategy\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    99. Cache Invalidation Summary<\/h1>\n\n\n\n
    Four common mechanisms:<\/p>\n\n\n\n
    1. TTL expiration\n\n2. Delete on database change\n\n3. Update cache on database change\n\n4. Event-driven invalidation\n<\/code><\/pre>\n\n\n\n
    A strong production architecture often combines:<\/p>\n\n\n\n
    Active invalidation\n+\nTTL safety net\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    100. Stampede Summary<\/h1>\n\n\n\n
    Problem:<\/p>\n\n\n\n
    Popular key expires\n       \u2193\nThousands of MISSes\n       \u2193\nThousands of DB queries\n       \u2193\nDatabase overload\n<\/code><\/pre>\n\n\n\n
    Solutions include:<\/p>\n\n\n\n
    TTL jitter\n\nSingle refresher \/ mutex\n\nStale-while-revalidate\n\nRequest coalescing\n\nEarly refresh\n\nBackend rate protection\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    101. Connection Pooling Summary<\/h1>\n\n\n\n
    Do:<\/p>\n\n\n\n
    Application process\n       |\n       v\nReusable Redis client\n       |\nPool \/ multiplexed connections\n       |\n       v\nRedis\n<\/code><\/pre>\n\n\n\n
    Avoid:<\/p>\n\n\n\n
    Every request\n    \u2193\nNew connection\n    \u2193\nRedis\n    \u2193\nClose connection\n<\/code><\/pre>\n\n\n\n
    And remember:<\/p>\n\n\n\n
    pool size\n\u00d7\napplication instance count\n=\ntotal potential connections\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    102. Failure Handling Summary<\/h1>\n\n\n\n
    For each Redis use case ask:<\/p>\n\n\n\n
    What happens if Redis disappears for 30 seconds?\n<\/code><\/pre>\n\n\n\n
    Cache:<\/p>\n\n\n\n
    Maybe bypass Redis.\n<\/code><\/pre>\n\n\n\n
    Session:<\/p>\n\n\n\n
    Maybe temporarily unavailable\/re-authenticate.\n<\/code><\/pre>\n\n\n\n
    Rate limiter:<\/p>\n\n\n\n
    Choose fail-open or fail-closed intentionally.\n<\/code><\/pre>\n\n\n\n
    Lock:<\/p>\n\n\n\n
    Do not blindly continue.\n<\/code><\/pre>\n\n\n\n
    Pub\/Sub:<\/p>\n\n\n\n
    Messages during disconnect may be lost.\n<\/code><\/pre>\n\n\n\n
    Counter:<\/p>\n\n\n\n
    Decide whether temporary loss\/unavailability matters.\n<\/code><\/pre>\n\n\n\n
    The same Redis failure cannot have one identical fallback strategy for every use case.<\/p>\n\n\n\n
    \n\n\n\n
    103. Production Redis Golden Rules<\/h1>\n\n\n\n
    Rule 1<\/h3>\n\n\n\n
    Treat the database as the source of truth when Redis is being used purely as a cache.<\/p>\n\n\n\n
    Rule 2<\/h3>\n\n\n\n
    Use the Redis data structure that naturally represents the problem.<\/p>\n\n\n\n
    Rule 3<\/h3>\n\n\n\n
    Do not cache everything.<\/p>\n\n\n\n
    Rule 4<\/h3>\n\n\n\n
    Give temporary cache data a deliberate expiration strategy.<\/p>\n\n\n\n
    Rule 5<\/h3>\n\n\n\n
    Use TTL jitter for large groups of similarly expiring keys.<\/p>\n\n\n\n
    Rule 6<\/h3>\n\n\n\n
    Design cache invalidation before production.<\/p>\n\n\n\n
    Rule 7<\/h3>\n\n\n\n
    Protect the database from cache failure.<\/p>\n\n\n\n
    Rule 8<\/h3>\n\n\n\n
    Use bounded retries and timeouts.<\/p>\n\n\n\n
    Rule 9<\/h3>\n\n\n\n
    Reuse Redis connections through the architecture supported by your client.<\/p>\n\n\n\n
    Rule 10<\/h3>\n\n\n\n
    Monitor hits, misses, memory, evictions, latency and backend load.<\/p>\n\n\n\n
    Rule 11<\/h3>\n\n\n\n
    Do not use Pub\/Sub when you require durable delivery.<\/p>\n\n\n\n
    Rule 12<\/h3>\n\n\n\n
    Treat Redis locks as leases, not magical distributed transactions.<\/p>\n\n\n\n
    Rule 13<\/h3>\n\n\n\n
    Use unique lock ownership tokens.<\/p>\n\n\n\n
    Rule 14<\/h3>\n\n\n\n
    Never depend blindly on stale cached data for critical decisions.<\/p>\n\n\n\n
    Rule 15<\/h3>\n\n\n\n
    Design Redis failure behavior before Redis actually fails.<\/p>\n\n\n\n
    \n\n\n\n
    104. The Complete Mental Model<\/h1>\n\n\n\n
    If you remember only one diagram from this tutorial, remember this:<\/p>\n\n\n\n
    flowchart TB\n\n    CLIENT[Clients]\n\n    APP[Application Layer]\n\n    POOL[Redis Client \/ Connection Pool]\n\n    REDIS[(Redis)]\n\n    DB[(Authoritative Database)]\n\n    EVENTS[Durable Event System]\n\n    CLIENT --> APP\n\n    APP --> POOL\n\n    POOL --> REDIS\n\n    APP --> DB\n\n    APP --> EVENTS\n\n    REDIS -->|Cache \/ Sessions \/ Counters \/ Locks| APP\n\n    DB -->|Source of Truth| APP\n<\/code><\/pre>\n\n\n\n
    Redis is positioned where fast shared state<\/strong> creates value.<\/p>\n\n\n\n
    \n\n\n\n
    105. Redis in One Sentence<\/h1>\n\n\n\n
    \n
    Redis is a high-speed shared data-structure store that applications commonly use to reduce expensive work and coordinate temporary state, but every Redis use case must have deliberate policies for freshness, expiration, durability and failure.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    106. Final Topic Map<\/h1>\n\n\n\n
    You can now connect the complete learning journey:<\/p>\n\n\n\n
    flowchart TD\n\n    A[Redis Fundamentals]\n\n    B[Redis Data Structures]\n\n    C[Caching]\n\n    D[Cache-Aside]\n\n    E[Read\/Write-Through]\n\n    F[TTL]\n\n    G[Cache Invalidation]\n\n    H[Stampede & Staleness]\n\n    I[Pub\/Sub]\n\n    J[Sessions]\n\n    K[Counters]\n\n    L[Distributed Locks]\n\n    M[Connection Pooling]\n\n    N[Failure Handling]\n\n    O[When NOT to Use Redis]\n\n    P[Production Redis Architecture]\n\n    A --> B\n    B --> C\n    C --> D\n    D --> E\n    E --> F\n    F --> G\n    G --> H\n\n    H --> I\n    H --> J\n    H --> K\n    H --> L\n\n    I --> M\n    J --> M\n    K --> M\n    L --> M\n\n    M --> N\n    N --> O\n    O --> P\n<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    107. Final GOLD Standard Comparison<\/h1>\n\n\n\n
    Topic<\/th>Core Question<\/th>Key Redis Concept<\/th><\/tr><\/thead>
    Redis<\/td>Why use it?<\/td>Fast shared state<\/td><\/tr>
    Data structures<\/td>How should data be represented?<\/td>String\/Hash\/List\/Set\/ZSet\/Stream<\/td><\/tr>
    Cache-aside<\/td>Who manages cache misses?<\/td>Application<\/td><\/tr>
    Read-through<\/td>Who loads missing data?<\/td>Cache abstraction<\/td><\/tr>
    Write-through<\/td>How are writes synchronized?<\/td>Cache + DB write path<\/td><\/tr>
    TTL<\/td>How long may data live?<\/td>Expiration<\/td><\/tr>
    Invalidation<\/td>How do we remove stale copies?<\/td>Delete\/update\/event<\/td><\/tr>
    Stampede<\/td>What if many misses occur together?<\/td>Jitter\/locking\/SWR<\/td><\/tr>
    Stale data<\/td>How old may data safely become?<\/td>Freshness policy<\/td><\/tr>
    Pub\/Sub<\/td>Need real-time ephemeral broadcast?<\/td>PUBLISH<\/code> \/ SUBSCRIBE<\/code><\/td><\/tr>
    Sessions<\/td>Need shared temporary user state?<\/td>Hash\/String + TTL<\/td><\/tr>
    Counters<\/td>Need atomic shared numbers?<\/td>INCR<\/code><\/td><\/tr>
    Lightweight locks<\/td>Need temporary coordination?<\/td>SET NX EX\/PX<\/code><\/td><\/tr>
    Pooling<\/td>How should applications connect efficiently?<\/td>Reuse\/multiplex<\/td><\/tr>
    Failure handling<\/td>What happens when Redis fails?<\/td>Fallback\/circuit breaker<\/td><\/tr>
    Don’t use Redis<\/td>Is Redis actually the right system?<\/td>Architectural judgment<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n
    108. The Most Important Redis Lesson<\/h1>\n\n\n\n
    Learning Redis commands is relatively easy:<\/p>\n\n\n\n
    GET\nSET\nDEL\nEXPIRE\nHSET\nSADD\nZADD\nINCR\nPUBLISH\nSUBSCRIBE\n<\/code><\/pre>\n\n\n\n
    The difficult\u2014and valuable\u2014part is learning to answer:<\/p>\n\n\n\n
    Should this data be cached?\n\nWho owns the truth?\n\nHow long may the cached copy live?\n\nHow is it invalidated?\n\nWhat if the key expires during heavy traffic?\n\nWhat if Redis goes down?\n\nWhat if the database goes down?\n\nCan stale data hurt the business?\n\nDo I need durability?\n\nDo I need atomicity?\n\nDo I actually need Redis?\n<\/code><\/pre>\n\n\n\n
    When you can answer those questions, you are no longer simply using Redis commands<\/strong>.<\/p>\n\n\n\n
    You are designing a production Redis architecture<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":"
    From Fundamentals to Production-Grade Caching, Sessions, Pub\/Sub, Counters, Locks and Failure Handling 1. What is Redis? Redis is a high-performance, primarily in-memory data store. The easiest mental… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1150","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1150","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=1150"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1150\/revisions"}],"predecessor-version":[{"id":1151,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1150\/revisions\/1151"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1150"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1150"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1150"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}