Caching strategies in FastAPI - Step-by-Step Execution

Concept Flow - Caching strategies

Client Request

↓

Check Cache

↓

Return

↓

Store in Cache

↓

Return Data

When a client requests data, the system first checks if the data is in cache (Hit). If yes, it returns cached data immediately. If not (Miss), it fetches fresh data, stores it in cache, then returns it.

Execution Sample

FastAPI

from fastapi import FastAPI
from fastapi_cache import FastAPICache
from fastapi_cache.backends.inmemory import InMemoryBackend
from fastapi_cache.decorator import cache

app = FastAPI()

@app.on_event("startup")
async def startup():
    backend = InMemoryBackend()
    FastAPICache.init(backend, prefix="fastapi-cache")

@app.get("/items/{item_id}")
@cache(expire=10)
async def read_item(item_id: int):
    return {"item_id": item_id, "value": "fresh data"}

This FastAPI endpoint caches responses for 10 seconds to speed up repeated requests for the same item.

Execution Table

Step	Action	Cache State	Result	Notes
1	Client requests /items/1	Empty	Cache miss	No cached data for item 1
2	Fetch fresh data for item 1	Empty	{"item_id":1,"value":"fresh data"}	Data fetched from source
3	Store data in cache with 10s expiry	{"1": cached}	Data cached	Cache now holds item 1 data
4	Return data to client	{"1": cached}	Response sent	Client receives fresh data
5	Client requests /items/1 again	{"1": cached}	Cache hit	Data served from cache
6	Return cached data	{"1": cached}	Response sent	Faster response from cache
7	Wait 11 seconds (cache expires)	Empty	Cache expired	Cached data removed after expiry
8	Client requests /items/1 again	Empty	Cache miss	Cache empty, fetch fresh data again

💡 Cache expires after 10 seconds, causing next request to fetch fresh data again

Variable Tracker

Variable	Start	After Step 3	After Step 6	After Step 7	After Step 8
cache	{}	{"1": cached}	{"1": cached}	{}	{}

Key Moments - 3 Insights

Why does the first request cause a cache miss?

Because the cache is empty at the start (see execution_table step 1), no data is stored yet for the requested item.

How does the cache improve response time on repeated requests?

On repeated requests (step 5), the cache has stored data, so the system returns cached data immediately without fetching fresh data (step 6).

What happens when the cache expires?

After the expiry time (step 7), cached data is removed, so the next request (step 8) results in a cache miss and fresh data fetch.

Visual Quiz - 3 Questions

Look at the execution table, what is the cache state at step 5?

A {"1": cached}

B {}

C Empty

D Expired

💡 Hint

Check the 'Cache State' column at step 5 in the execution_table

At which step does the cache expire?

A Step 3

B Step 7

C Step 6

D Step 8

💡 Hint

Look for the step where 'Cache expired' is noted in the 'Result' column

If the cache expiry was set to 20 seconds instead of 10, what would change in the execution table?

A Step 7 would show cache still valid, no expiry

B Step 1 would be a cache hit

C Step 8 would be a cache hit instead of miss

D Step 3 would not store data

💡 Hint

Consider when the cache expires and how it affects step 8's cache miss/hit

Concept Snapshot

Caching strategies in FastAPI:
- Check cache before fetching data
- If cache hit, return cached data immediately
- If cache miss, fetch fresh data, store in cache
- Use decorators like @cache(expire=seconds) to set expiry
- Cache expiry removes old data to keep cache fresh

Full Transcript

This visual execution shows how caching works in FastAPI. When a client requests data, the system first checks if the data is in cache. If not found (cache miss), it fetches fresh data, stores it in cache with an expiry time, then returns it. Subsequent requests within the expiry time get data instantly from cache (cache hit). After expiry, cached data is removed, causing the next request to fetch fresh data again. This speeds up responses and reduces repeated work.

Practice

1. What is the main purpose of using caching in a FastAPI application?

easy

A. To increase the size of the application code

B. To remove all data from the server

C. To make the app slower for testing

D. To save repeated work and speed up response times

Solution

1. Step 1: Understand caching concept

   Caching stores results of expensive operations to reuse later.

2. Step 2: Identify caching benefit in FastAPI

   This reuse saves repeated work and speeds up response times.

3. Final Answer:

   To save repeated work and speed up response times -> Option D

4. Quick Check:

   Caching purpose = speed up responses [OK]

Hint: Caching means saving work to respond faster [OK]

Common Mistakes:

• Thinking caching increases code size
• Believing caching slows down the app
• Confusing caching with deleting data

2. Which of the following is the correct way to apply caching with expiration in FastAPI using the decorator?

easy

A. @cache(expire=60)

B. @cache_time(60)

C. @cache(expiration=60)

D. @cache(60_seconds)

Solution

1. Step 1: Recall FastAPI cache decorator syntax

   The correct decorator is @cache(expire=seconds) to set expiration time.

2. Step 2: Match options with correct syntax

   Only @cache(expire=60) matches the correct pattern.

3. Final Answer:

   @cache(expire=60) -> Option A

4. Quick Check:

   Decorator with expire=60 is correct [OK]

Hint: Use @cache with expire=seconds for expiration [OK]

Common Mistakes:

• Using wrong decorator names like @cache_time
• Using incorrect parameter names like expiration
• Passing expiration time without parameter name

3. Given this FastAPI code snippet, what will be the output on the second call to /data within 10 seconds?

from fastapi import FastAPI
from fastapi_cache.decorator import cache

app = FastAPI()

@cache(expire=10)
async def get_data():
    print('Fetching data')
    return {'value': 42}

@app.get('/data')
async def data():
    return await get_data()

medium

A. {'value': 42} and prints 'Fetching data' once only

B. {'value': 42} and prints 'Fetching data' every call

C. Error because cache decorator is missing setup

D. Empty response because cache expired immediately

Solution

1. Step 1: Check for cache initialization

   The code uses @cache but lacks FastAPICache.init with a backend on startup.

2. Step 2: Analyze execution

   Without init, FastAPICache.get raises AttributeError on first call, before executing get_data or printing.

3. Final Answer:

   Error because cache decorator is missing setup -> Option C

4. Quick Check:

   Missing FastAPICache.init causes runtime error [OK]

Hint: Cache decorator requires FastAPICache.init on startup [OK]

Common Mistakes:

• Assuming caching works without FastAPICache.init, print once only
• Thinking no caching, print every call
• Believing cache expires immediately

4. Identify the error in this FastAPI caching setup:

from fastapi import FastAPI
from fastapi_cache import FastAPICache
from fastapi_cache.backends.inmemory import InMemoryBackend

app = FastAPI()

@app.on_event('startup')
async def startup():
    FastAPICache.init(InMemoryBackend())

@cache(expire=30)
async def get_info():
    return {'info': 'cached data'}

medium

A. InMemoryBackend requires a Redis URL parameter

B. Cache decorator is used without importing it

C. Missing await keyword when calling FastAPICache.init

D. Startup event should be named 'start' instead of 'startup'

Solution

1. Step 1: Check imports for cache decorator

   The code uses @cache but does not import it from fastapi_cache.decorator.

2. Step 2: Verify other parts for correctness

   FastAPICache.init is correctly called; InMemoryBackend needs no parameters; event name 'startup' is correct.

3. Final Answer:

   Cache decorator is used without importing it -> Option B

4. Quick Check:

   Missing import of cache decorator causes error [OK]

Hint: Always import @cache decorator before using it [OK]

Common Mistakes:

• Forgetting to import cache decorator
• Passing Redis URL to InMemoryBackend
• Renaming startup event incorrectly

5. You want to cache user profile data in FastAPI using Redis backend with a 5-minute expiration. Which setup correctly initializes caching and applies it to the get_user_profile function?

from fastapi import FastAPI
from fastapi_cache import FastAPICache
from fastapi_cache.backends.redis import RedisBackend
from fastapi_cache.decorator import cache
import aioredis

app = FastAPI()

@app.on_event('startup')
async def startup():
    redis = aioredis.from_url('redis://localhost')
    FastAPICache.init(RedisBackend(redis), prefix='fastapi-cache')

@cache(expire=300)
async def get_user_profile(user_id: int):
    # Simulate fetching user profile
    return {'user_id': user_id, 'name': 'Alice'}

hard

A. Correct setup: Redis backend initialized with aioredis, cache decorator with expire=300

B. Incorrect: RedisBackend needs a string URL, not aioredis instance

C. Incorrect: Cache decorator expire should be in milliseconds, not seconds

D. Incorrect: FastAPICache.init must be called inside the cached function

Solution

1. Step 1: Verify Redis backend initialization

   Using aioredis.from_url and passing RedisBackend(redis) is correct for Redis caching.

2. Step 2: Check cache decorator usage

   @cache(expire=300) sets 5 minutes expiration correctly in seconds.

3. Final Answer:

   Correct setup: Redis backend initialized with aioredis, cache decorator with expire=300 -> Option A

4. Quick Check:

   Redis backend + expire=300 seconds = correct caching [OK]

Hint: Use aioredis instance with RedisBackend and expire in seconds [OK]

Common Mistakes:

• Passing Redis URL string directly instead of aioredis instance
• Using expire in milliseconds instead of seconds
• Calling FastAPICache.init inside cached function