API Caching

API Caching

Have you ever heard about API caching?

In a simple scenario, when a client requests some resource, the backend sends a request to the database, the database returns the actual data, and the backend returns a representation of that resource (json response).

For example:

GET /products/15

The flow is usually:

Client -> Backend -> Database -> Backend -> Resource representation for client

This guarantees that the latest data is returned.

But there is a problem.

Imagine:

• 10 users request the same product,
• then 100 users,
• then 100 000 users.

Without caching:

• every request reaches the backend,
• every backend instance sends requests to the database,
• the database receives huge read load.

Even with multiple backend instances and database replicas, this may become expensive under high load.

This is where caching appears.

For example:

• User A requests product 15,
• backend receives data from the database,
• backend stores the response in cache.

Now User B requests the same product.

Instead of going again:

Backend -> Database

the backend may return the already cached response.

This solves several problems:

• reduces database load
• improves response time
• decreases infrastructure costs
• helps the system scale for large numbers of users.

In production systems, caching is often a necessity rather than an optimization.

However, caching introduces another problem.

1. Product data was cached.
2. Product price changed in the database.
3. Cache lifetime is still valid.
4. Users continue receiving the old value.

For example:

• old price
• outdated profile information
• stale permissions
• old feature flags.

This happens because the system temporarily prioritizes performance over immediate consistency.

And this is an important engineering trade-off.

Long cache lifetime:

• better performance
• lower database load
• faster responses,l
• but higher risk of stale data.

Short cache lifetime:

• fresher data
• lower inconsistency risk
• but higher infrastructure load

Because of this, production systems carefully choose cache lifetime depending on business risk.

For example:

• product catalog may be cached for minutes
• stock prices maybe only milliseconds
• authentication or permission data may avoid caching completely.

Another important thing: cache may exist not only inside backend applications.

Caching may happen in:

• backend application memory
• API Gateway
• CDN
• browser
• ORM/framework internal cache
• database internal cache.

This may confuse (to the heart attack) not only an end user or QA, but also DevOps or support engineer.

From a QA perspective, an important question is how do we even understand that caching exists?

One of the first places to look is HTTP response headers.

For example:

Cache-Control: max-age=60

ETag: "product-v15"

Age: 25 Expires: Wed, 29 May 2026 10:00:00 GMT

These headers may indicate:

• whether caching is enabled,
• how long responses stay valid
• whether the response came from cache
• whether revalidation mechanisms exist.

They can be inspected in:

• browser dev tools
• http clients (Postman or RestAssured)

From a QA perspective, caching creates several important questions.

Should cache be disabled on test environments?

Sometimes yes.

Especially when:

• functional tests validate fresh data,
• deterministic behavior is required,
• test isolation is important.

But fully disabling cache may hide production-specific issues.

Because many real defects appear only when:

• multiple instances exist
• cache invalidation is delayed
• distributed synchronization happens
• replicas lag behind
• stale data temporarily exists.

That is why mature QA strategies often use both approaches:

• environments with disabled cache for stable functional validation,
• environments with realistic caching enabled for production-like behavior testing (production-equivalent environments).

Typical QA validations for caching:

• stale data detection,
• cache invalidation after PUT/PATCH/DELETE,
• consistency between instances,
• deployment behavior,
• response differences under load balancing,
• cache TTL expiration,
• authorization-aware caching,
• ensuring sensitive data is never shared between users.

Caching is one of those topics where “it works on my machine”, works differently on the test server and “what the hell is going in production”.

Check your API cache now ☺️