Response caching strategies in GraphQL - Time & Space Complexity

Time Complexity: Response caching strategies

O(1)

Understanding Time Complexity

When using response caching in GraphQL, we want to know how the time to get data changes as requests grow.

We ask: How does caching affect the work done when many queries come in?

Scenario Under Consideration

Analyze the time complexity of the following GraphQL query with response caching.

query GetBooks {
  books {
    id
    title
    author {
      name
    }
  }
}

This query fetches a list of books with their authors. We consider caching the full response for repeated queries.

Identify Repeating Operations

Look for repeated work when many queries happen.

• Primary operation: Fetching and assembling the list of books and authors from the database.
• How many times: Without caching, this happens every time the query runs. With caching, it happens once per unique query.

How Execution Grows With Input

Think about how work changes as requests increase.

Input Size (number of queries)	Approx. Operations
10	10 database fetches without cache, 1 fetch with cache
100	100 fetches without cache, 1 fetch with cache
1000	1000 fetches without cache, 1 fetch with cache

Pattern observation: Without caching, work grows linearly with queries. With caching, work stays almost the same after the first fetch.

Final Time Complexity

Time Complexity: O(1)

This means after the first query, getting the response again takes about the same small amount of time, no matter how many queries come.

Common Mistake

[X] Wrong: "Caching makes every query faster by skipping all work every time."

[OK] Correct: The first query still does all the work to build the response. Caching only helps for repeated identical queries.

Interview Connect

Understanding how caching changes work helps you explain how to make APIs faster and handle many users smoothly.

Self-Check

"What if we cache parts of the response instead of the whole? How would that change the time complexity?"