Filesystem or Redis Cache Adapter for a Symfony App Approaching Multi-Server Deployment

Direct answer

For a read‑heavy, low‑write Symfony 6.4 app that will run on three load‑balanced nodes, you can keep the filesystem cache adapter only if you can tolerate brief inconsistencies and you have an automated warmer that runs on each node after every deployment. If strict cache consistency or avoidance of duplicate warm‑ups and cache‑stampede is required, switch to a shared adapter (Redis) before you add the second node.

Likely explanation

The filesystem adapter gives the lowest local‑read latency and needs no external service, but each node maintains its own copy. Under read‑heavy traffic this leads to redundant warm‑up work and, after a cache clear, a simultaneous miss spike on all nodes (a stampede). Redis eliminates duplication by sharing entries and provides atomic TTL handling, at the cost of a small network round‑trip (≈0.5‑1 ms on a LAN) and extra operational overhead.

Confirmed facts (from the research brief)

• For read‑heavy, infrequent‑write workloads, per‑node filesystem caching is acceptable when short‑lived inconsistencies are tolerable and each node can warm its cache independently.
• When cached data must be identical across nodes (doctrine result/annotation cache, serializer metadata, CSRF tokens, etc.) or when cache‑stampede protection is needed, a shared adapter such as Redis removes duplicate warm‑ups and guarantees atomic TTL.
• Empirical observations show that sustained traffic above roughly 200‑300 requests per second per node, with filesystem cache‑hit ratios falling below 90 %, often indicates that the cost of redundant warm‑ups and missed hits outweighs the sub‑millisecond LAN latency of Redis.
• Write frequency is less decisive; even a few writes per second are safely handled by Redis atomic operations, whereas filesystem adapters may suffer from file‑locking contention under concurrent writes.

Steps to decide for your case

1. Identify which cache pools require strict consistency (e.g., doctrine.metadata, serializer, annotation, CSRF). If any of these are used, plan to move those pools to Redis.
2. Deploy a load‑test that mimics the expected three‑node traffic profile (use k6, Locust, or similar). Capture per‑node cache‑hit ratio, average response time, and 95th‑percentile latency for both the filesystem and Redis adapters.
3. After a warm cache, measure the baseline hit ratio. Then simulate a cache clear (e.g., php bin/console cache:pool:clear cache.app) and monitor the miss rate spike. If the miss rate stays above ~20 % for more than a few seconds, a shared adapter is likely needed.
4. If the hit ratio stays ≥90 % and the latency increase from moving to Redis is negligible (<1 ms) under load, you may keep the filesystem adapter, provided you run an automated warmer on each node after each deployment.
5. Document the tolerance for stale data (e.g., "menu items may be stale for up to 30 seconds") and confirm with stakeholders that this is acceptable.

Missing diagnostic detail that could change the recommendation

Do you require strict TTL consistency for any cached data (e.g., security tokens, form CSRF, or doctrine metadata), or can you accept brief inconsistencies? If strict consistency is required, the recommendation shifts to moving to Redis before scaling; otherwise, per‑node filesystem caching with warmers remains viable.