Marc Brooker

And so, you know, obviously very attractive.

But...

The downside of caches, especially in distributed systems, is they have this mode.

There's a mode where the cache is full and the cache is full of the right data in time and space to perform very well.

And there's a mode where the cache is empty or contains the wrong data.

And in the first mode, the system is fast and happy and healthy.

In the second mode, the system is slow, often down because now the backend isn't scaled to deal with all of this uncashed traffic.

Customers are very disappointed.

And often it is down in a stable way.

And this is this kind of idea of metastable failures where the system has switched from state one to state two.

And in state two, it's still stable, right?

Like it's still, it's down, but it's not gonna come back up under its own energy because for example,

all of this traffic is causing a huge amount of contention in my database or is saturating the network.

And so I can't even refill the cache.

It's not even getting the right kind of data in.

And so, you know, when I talk about the downsides of caches, it's really about, you know, how do we avoid that modality between, you know, fast and, you know, that value of caches and the, you know, how do we avoid the state where we're down?

And so if I go back to D-SQL, our answer there is D-SQL, what we call the storage tier, is essentially a cache, but it is a complete cache.

It contains every row in the database.

And so it doesn't have this mode where how do I recover from it being empty or containing the wrong data?

It contains all of the data.