Micro Caching in Checkout | How to Cache Dynamic Content with Short TTL

Learn how to apply Micro Caching to shipping, promotions, and stock to reduce checkout latency without compromising transactional data. Technical guide with TTL table and practical examples.

The belief that checkout can’t be cached is costly. Many resources in the transactional flow are repetitive and read-only — and can be safely accelerated using TTL of seconds. Micro Caching applies extremely short cache windows for dynamic data like shipping, promotions, and stock. Granular Caching complements this strategy by defining precise segmentation keys. Together, they reduce latency, protect the origin, and maintain transactional data integrity.


Introduction: the cost of checkout that doesn’t cache

There’s a deeply rooted belief in e-commerce engineering: checkout can’t be cached.

This decision has a real cost. During traffic spikes, every read request that goes to the origin unnecessarily consumes capacity that should be reserved for critical transactional operations — payment authorization, stock confirmation, order finalization.

The result is predictable: accumulated latency, intermittent timeouts, and cart abandonment exactly when purchase intent is at its peak.

The problem isn’t that checkout is dynamic. The problem is treating all checkout data as equally sensitive.

In practice, many requests in the checkout flow are predominantly read or repetitive under load. They can be accelerated — with the right controls.


1. What is Micro Caching?

Micro Caching is the technique of storing dynamic content for extremely short time windows — typically between 1 and 10 seconds.

This window is short enough to ensure data remains relevant, but long enough to absorb bursts of simultaneous requests before they reach the origin.

Micro Caching isn’t the same as traditional cache.

Traditional cache stores static content for minutes, hours, or days. Micro Caching operates on a seconds scale and is specifically designed for data that changes frequently, but not every millisecond.

Explicit difference between cluster strategies

It’s important to make clear the distinction between Micro Caching and other cluster strategies to avoid confusion:

StrategyQuestion it answersFocus
Micro CachingHow long to cache?Short TTL for dynamic data
Tiered CacheHow many layers to cache?Hierarchy between nodes and origin
Granular CachingWhat to cache and with what rule?Segmentation by headers and cookies

All three are complementary — not mutually exclusive.


2. What can and cannot be cached with Micro Caching

The correct separation between cacheable and non-cacheable data is the foundation of a safe Micro Caching strategy.

ResourceCacheable?Recommended TTLJustification
Shipping calculation by ZIP code range✅ Yes5 to 10 secondsChanges little in short intervals, but is heavily consulted during spikes
Promotion previews and eligibility✅ Yes2 to 5 secondsCampaign rules are stable during flash sale execution
Stock level for display✅ Yes3 to 5 secondsProvides stable response while central system processes reservations
Feature flags and session configurations✅ Yes5 to 30 secondsLow variation, high query volume
Catalog and product fragments✅ Yes10 to 60 secondsRead data with controlled versioning
Cart summary⚠️ With care1 to 2 seconds with key per sessionRequires immediate invalidation when state changes
Payment methods list✅ Yes30 to 60 secondsRarely changes during an active session
Payment authorization❌ NoAlways transactional — never cache
Order finalization❌ NoUnrepeatable write operation
Any state-altering operation❌ NoNo cache without idempotency controls

Practical rule: if data is read-only and can be shared between multiple users without risk of session contamination, it can probably be accelerated with Micro Caching.


3. Zero TTL: when time is the smallest possible

Zero TTL is an extreme case of Micro Caching where storage time is reduced to the functional minimum — often fractions of a second or the time needed to resolve a burst of simultaneous requests.

Zero TTL isn’t the same as cache bypass.

Bypass ignores cache completely and sends each request directly to the origin. Zero TTL still uses cache as a coordination mechanism — it stores the response long enough to prevent identical simultaneous requests from overloading the backend.

When to use Zero TTL

  • data that changes every few seconds but has concentrated query spikes
  • high-concurrency endpoints where any positive TTL represents stale data risk
  • situations where Request Coalescing needs additional support for extreme spikes

→ To understand how Request Coalescing complements Zero TTL in Thundering Herd scenarios: Request Coalescing: How to Eliminate Thundering Herd in Checkout


4. Granular Caching as a complement

If Micro Caching defines how long to cache, Granular Caching defines what to cache — and with what segmentation criteria.

Using Advanced Cache Keys, you can store different versions of the same resource based on specific HTTP request information:

Segmentation by cookie Allows caching cart summary fragments or session in isolation, ensuring one customer never receives another’s data.

Segmentation by header Serves different API versions based on Device-Type, Accept-Language, or User-Segment — without duplicating logic in the application.

Segmentation by query string Essential for recommendation APIs, search filters, and campaign parameters that generate dynamic URLs.

How to combine Micro Caching and Granular Caching

The combination works like this:

  1. Micro Caching defines the time window — how many seconds data can be reused
  2. Granular Caching defines the key — which combination of headers, cookies, or query strings uniquely identifies this data
  3. Selective bypass ensures the boundary — critical operations like payment bypass cache completely
Shipping request
[Granular Cache Key: ZIP prefix + Device-Type]
[Micro Cache TTL: 5 seconds]
Cache HIT → immediate response
Cache MISS → origin → populates cache → response

See the Marisa case, which combined Micro Caching and Granular Caching modernizing their architecture with distributed execution and granular control: https://www.azion.com/en/success-case/marisa/


5. Selective bypass: protecting critical operations

It’s not enough to know what to cache. You need to ensure operations that shouldn’t be cached never go through cache — regardless of general configuration.

Selective bypass applies an explicit rule per endpoint or operation type:

OperationCorrect behavior
GET /api/shipping-optionsMicro Caching with 5s TTL
GET /api/promotions/eligibilityMicro Caching with 3s TTL
POST /api/cart/updateTotal bypass — always to origin
POST /api/payment/authorizeTotal bypass — always to origin
POST /api/order/confirmTotal bypass — always to origin

The boundary between what’s accelerated and what’s transactional must be explicit in configuration — not assumed.


6. Implementation: the role of stale-while-revalidate and key-based purge

Two techniques complement Micro Caching in practice. They were covered in depth on the Tiered Cache page, but it’s worth contextualizing their role here:

Stale-while-revalidate While TTL expires and data is updated in the background, the user receives the cached version without perceiving latency. During traffic spikes, this preserves checkout availability even when the origin starts to degrade.

Key-based purge When cart state changes or a price is updated, invalidation must be surgical — removing only the affected key, without impacting the rest of the application.

→ For detailed implementation of these techniques: Tiered Cache: How to Reduce Origin Load in Checkout and APIs


7. Programmable cache: from static configuration to contextual logic

The advancement of Micro Caching lies in going beyond static TTL rules. With programmable cache, you can define by code how each request should be handled directly in distributed infrastructure.

This means teams can:

  • test new cache strategies without rebuilding the infrastructure layer
  • adjust TTL per user segment in real-time
  • pre-warm caches before major campaigns
  • automate invalidations based on stock or promotion events
  • integrate cache rules directly into application workflows via APIs

During a flash sale, for example, Micro Caching rules can be automatically activated for high-concurrency endpoints — and deactivated when the spike passes — without manual intervention.


8. Real example: Marisa

Marisa is a concrete example of how intelligent cache transforms the relationship between performance and cost in enterprise e-commerce.

With Azion’s distributed infrastructure, Marisa started delivering more than 85% of their data directly in distributed layers, without querying the origin.

The result was:

MetricResult
Data delivered in distributed infrastructure85%
Bandwidth savings per day4.3 TB
Stability during high-demand periods✅ Maintained
Faster pages with lower costs✅ Confirmed

Saving 4.3 TB of bandwidth per day isn’t just an infrastructure metric. It’s the difference between a checkout that handles the spike and one that silently degrades.


9. FAQ

What is Micro Caching?

It’s the technique of storing dynamic content for very short time windows — typically between 1 and 10 seconds — to reduce pressure on the origin without compromising data freshness.

What’s the difference between Micro Caching and Zero TTL?

Micro Caching uses TTL of seconds to balance performance and freshness. Zero TTL reduces this time to the functional minimum — enough to coordinate simultaneous requests without delivering stale data.

Can Micro Caching compromise transactional data?

No, if the boundary between cacheable data and transactional operations is explicit. Payment authorization, order finalization, and any state-altering operation should never be cached.

How to define the correct TTL for each resource?

The ideal TTL depends on two factors: the data update frequency and the risk of displaying a slightly outdated version. Shipping by ZIP code tolerates 5 to 10 seconds. Cart summary requires key per session and immediate invalidation when state changes.

What’s the difference between Micro Caching and Tiered Cache?

Micro Caching defines how long to cache — short TTL for dynamic data. Tiered Cache defines how many layers to distribute cache — hierarchy between presence nodes and origin. They’re complementary strategies.

When to use Granular Caching with Micro Caching?

Whenever the same resource needs different versions per user segment, device, or location. Granular Caching defines the key; Micro Caching defines the time window.

Does programmable cache replace static TTL configuration?

It doesn’t replace — it expands. Static configuration defines default behavior. Programmable cache adds contextual logic: different TTL per segment, automatic invalidation by business event, pre-warming before campaigns.


Conclusion

The biggest mistake in checkout cache management isn’t caching too much. It’s caching too little due to lack of control.

Micro Caching solves this with precision: TTL windows short enough to maintain data freshness, long enough to absorb traffic spikes before they overload the origin.

With Granular Caching as a complement and selective bypass as a safety boundary, it’s possible to accelerate most of the transactional flow without compromising the integrity of any critical operation.

The question isn’t whether checkout can be cached. The question is whether you have enough control to do it the right way.


Next steps

Check out Azion’s Cache solution and see how it implements Open Caching principles to ensure performance, resilience, and architectural freedom for global e-commerce operations. Want to build a checkout architecture without dependency on proprietary infrastructure?

Read Why Traditional Cache Fails When Your Customers Are Ready to Buy and understand how Open Caching and open architecture protect checkout performance at global scale.

Want to implement Micro Caching in your checkout safely?

Talk to an Azion specialist


stay up to date

Subscribe to our Newsletter

Get the latest product updates, event highlights, and tech industry insights delivered to your inbox.