Sulu Symfony HttpCache and Doctrine ORM: unresolved ESI surrogate caching decision for concurrent admin writes

Answer to the core questions

Does ESI surrogate caching for admin fragments risk stale data under concurrent writes? Yes – if a fragment is cached and a concurrent POST/PUT updates the underlying entity, the cached fragment will continue to be served until it is explicitly purged. Relying on TTL alone is insufficient because the cache key is not automatically tied to the entity’s write cycle.

Which invalidation boundaries should be configured? Invalidate the fragment cache at the aggregate‑root level: on each successful commit of a Doctrine transaction, delete or purge all ESI URLs that depend on the modified entity. Use cache tags if the store supports them, otherwise maintain a lookup table of fragment URLs per entity and purge them in one atomic step.

Is the latency spike mainly due to Symfony lock acquisition or Doctrine transaction commits? The majority of the latency originates from InnoDB row‑level locks that serialize concurrent writes to the same row. Symfony’s lock file is only engaged when a write request concurrently triggers a cache miss on a GET request; it does not serialize the write itself. Therefore, transaction commit time is the primary culprit, with Symfony locks adding a small overhead only for cache‑miss reads.

How to verify and mitigate the risk

1. Confirm cacheability of admin responses. Inspect the Cache‑Control and Surrogate‑Control headers on GET requests. If Cache‑Control: private is present, the fragment is not intended for shared caching and stale risk is moot.

2. Enable ESI tags or explicit URL purge. In your Symfony configuration, add a cache tag that matches the entity class or ID:

   framework:
     cache:
       pools:
         esi_fragment_pool:
           adapter: cache.adapter.redis
           default_lifetime: 3600
           tags: true
   

3. Hook into Doctrine lifecycle events. Use an onFlush or postFlush listener to collect all entities that changed and call the cache pool’s deleteTags or clear method with the corresponding tags.

4. Measure lock contention. Enable doctrine.dbal.logger to log SQL and symfony.http_cache.debug to log lock acquisition. Compare the average and 95th‑percentile times for sequential versus concurrent POST/PUT traces to isolate the contribution of each layer.

5. Check MySQL isolation level. While REPEATABLE READ can add gap locks, single‑row updates behave similarly to READ COMMITTED. If you observe range contention, consider switching to READ COMMITTED for admin writes.

When to reconsider ESI caching for admin fragments

• If the admin interface never displays cached fragments (e.g., all responses are Cache‑Control: private), disable surrogate caching to avoid unnecessary complexity.
• If you cannot guarantee atomic invalidation (e.g., using a third‑party cache without tag support), fallback to a short TTL and accept occasional staleness.
• Use a dedicated cache store for admin fragments to isolate them from public storefront caching, reducing the impact of cache purges on user traffic.

Ask for missing diagnostic detail

To fine‑tune the recommendation, could you confirm whether the admin GET responses currently include a Surrogate‑Control: content="ESI/1.0" header? This determines if the ESI processing step is actually active for the admin API.