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

I'm deploying a Symfony application (6.4 LTS) that currently runs on a single server using the default filesystem cache adapter defined in config/packages/cache.yaml. Read traffic is heavy and writes are infrequent, and the app performs well today. However, we're planning to scale horizontally to three nodes behind a load balancer within the next quarter, which raises the question of when the cache backend needs to change.

My understanding is that the filesystem adapter offers zero-dependency simplicity and fast local reads, but entries aren't shared across nodes, so each server maintains its own cache and warming becomes redundant work. The Redis adapter solves sharing and provides atomic operations with built-in TTL handling, but adds an external service to operate, plus network round-trip latency on every cache access.

What I can't find in the documentation is any concrete threshold—requests per second, node count, or write frequency—at which the trade-off clearly favors Redis. The decision seems to rest entirely on ad-hoc profiling.

Should the adapter switch happen before scaling out, or only after measuring actual cache-miss and stampede behavior under multi-node load? Is per-node filesystem caching with independent warmers a legitimate option for read-heavy workloads, or does it create consistency problems I'm underestimating? What metrics best indicate the filesystem adapter has become the bottleneck?