[ Strata ] A feature-complete Laravel filesystem cache with tagged cache support

[sunchayn]

One of the oldest issues in Laravel from 2014 was requesting tagging support for the Laravel filesystem cache (#3920).

This is still not solved idiomatically* in the framework or by third parties. The main reason was problems clearing the tagged cache.

*There are a couple of packages (mostly old) that aim to solve the issue, but the solutions weren't idiomatic regarding how tags were maintained and flushed.

The cache driver is important for two situations IMO:

• Low traffic or small websites.
• Local development for an app that has cache tags. If you have a driver that supports tags in production, you might need to use something else locally, such as filesystem. Without tag support, you will end up wrapping the tags logic in env checks.

For that reason, I released Strata, which is a drop-in replacement for the default filesystem driver with tagged cache support, isolated locks, and widened support for atomic operations.

Key Features:

• Drop-in Laravel cache API.
• Tag support.
• Isolated Atomic locks. Cache::lock() support backed by non-blocking file locks, stored apart from the cache system. Thus, a flush never releases a lock.
• Atomic increment/decrement. These are performed behind a lock, so concurrent calls don't overwrite each other (unlike in Laravel's default version).

Performance-wise, it is a bit faster for reads, especially for bulk reads. It has reduced overhead compared to the original version, and it checks cache eviction less eagerly. You can check the benchmark here, and the how it works wiki here.

[HIRATRA]

I was looking at the concurrency guarantees around Cache::flush() and had a question about its interaction with concurrent writes.

put() protects the individual cache file with a file lock, while flush() removes the cache directories and then clears the tag metadata. Is there an intended consistency guarantee when these operations overlap?

For example, if process A has acquired the lock for foo and is writing it while process B calls Cache::flush(), the flush can remove the directory while the write is in progress. Depending on the exact ordering, could the write effectively “reappear” after the flush?

I’m wondering whether flush() is intentionally best-effort in this respect, or whether there is a global coordination mechanism elsewhere that establishes a clear ordering between a store-wide flush and concurrent put() operations.

If the former is intentional, documenting that consistency boundary would be useful because the per-key atomicity guarantees are otherwise quite strong.

[sunchayn]

Hi,

put is not atomic; add is the one that is atomic.

As for your question about flush, flushing, by design, will wipe the entire cache disk. The operation is not atomic either.

This gives two situations with strata for the ongoing write operations:

1. Ongoing write (add or put) operation without tags.
2. Ongoing write operation with tags.

For the 1st situation, the cached value will reappear. For the 2nd situation, the cached value will not reappear because the tags will have expired by then (after the concurrent flush). The tag expiry is lazily checked on read.

This makes me wonder: what benefits do you envision in making the flush atomic? Do you have a situation where a cache value popping up after a flush is a problem? Isn't this what you would expect for the cache system?

---

If you were referring to this

Isolated Atomic locks. Cache::lock() support is backed by non-blocking file locks, stored apart from the cache system; thus, a flush never releases a lock.

If that is the case, that is about locks, which is a separate feature from the atomic operations (add, increment, decrement) themselves. The cache atomic operations use locks internally, but anything else outside the cache and in the main app code can use the locks independently.

Laravel's default driver stores locks as cache values. Thus, a flush will release the locks (even when there is a process protecting itself behind a lock). In strata, locks are handled separately. So even if the cache flushes, locks are not released, so the in-flight operations will keep their atomicity.

[HIRATRA]

That makes sense, and I agree that making flush() atomic isn't necessarily desirable if the cache semantics intentionally allow an in-flight write to complete after the flush.

My concern was less about making flush() atomic and more about making this concurrency behavior explicit. The distinction between untagged and tagged writes is particularly interesting: an untagged put() can reappear after flush(), while a tagged write won't because the tag metadata has already expired.

That seems like an important semantic detail worth capturing in the tests or documentation, especially since add() and put() have different atomicity guarantees.

Thanks for clarifying — I hadn't considered the lazy tag-expiry path when looking at the interaction between writes and flush().