>> Caching can make your application
more robust and run faster every day.
In this episode, learn how
FusionCache is making caching easy for things like
Azure SQL Database and how it's also won
an award this week on Data Exposed.
[MUSIC].
>> Hi, I'm Anna Hoffman,
and welcome to this episode of Data Exposed.
Today we have a very special guest joining us, Jody,
who is actually the creator and owner of FusionCache.
Jody, thanks so much for joining us today.
Can you tell us a little bit about what you do and FusionCache?
>> Yeah. Hi Anna, thanks for having me,
it's a pleasure to be here.
'm Jody and I am a coder and architect for 26 years already,
so a little bit of time.
FusionCache is my first open-source project
that is born out of the needs
that I encountered on
career by working with all different caching,
so like local caches, split cache,
CDNs, HTTP cache, stuff like that.
I tried to help the community, that was the idea,
by bringing some of these experiences into
a cohesive product and to releasing into the open.
>> Awesome, that's pretty exciting and
definitely cool to have the creator and owner on the show,
so we're so glad that you're joining us today.
>> Thank you.
>> For folks who might not be familiar
with why caching is important or what FusionCache,
I thought that you could take us through, hey,
this is what it does and these are
the benefits and this is why you should care and
especially as it relates maybe to
people using things like Azure SQL Database,
although I know it supports any database I think.
>> Yeah, it supports any data access technology.
In general, caching is what make,
for example, the web possible.
The web sits on top of
the HTTP GET verb and that is cacheable by default,
so without caching, the web will not exist as we know it today.
Apart from that, people mostly tend to introduce
caching into their applications to speed up a little bit things,
because it's a way to have the data
sit near the code that is executing our own code.
When we do that, we have pros and cons by using
typically the memory cache that sits
only in the memory of the application.
FusionCache tries to bring something to
the table and hopefully cues a way
to let the user benefit from having
an optional distributed second layer and
some advancements features that I
think are the most interesting ones.
I've prepared little slides.
>> Cool, let's take a look and learn some more.
>> As I said, it tries to be very easy to use.
If you know how to use caching as a whole,
like in memory caching.NET,
basically you already know how to use
FusionCache for the most user scenarios.
It's quite robust and fast,
I optimized it a little bit along the year
and it has
an optional distribution layer in someone advanced feature.
But how does it work?
Well, as they said, conceptually it's just the cache.
Imagine if you're using memory cache, you're to go.
But inside of it, there can be more things like the first level,
which is a memory cache,
which is very fast
because it's inside the memory of the application.
It is always there because it does not
depend on the network and it's very fast.
On the other hand, sometimes you may want to have
a distributed cache on top of your memory cache. Why is that?
Because even though it is fast but not as fast as a memory cache,
because it's out of process typically in
our machine like an instance of Redis,
or Memcached, or MongoDB or whatever.
It has the pro of being, again, out of process.
That means that for each application start or restart,
you will not have your cache wiped out,
which is what happens with the normal memory caches.
At the same time, if you are in a multi-node scenario,
you have a lot of nodes that have their own local memory cache
plus the distributed cache that
is a shared state that all can use.
But sometimes you may have synchronization issues like,
what is inside of each memory caching each node.
With the backplane, which is
the latest edition that I've made to FusionCache,
there's an automatic communication between
all the nodes to have everything synchronizing perfectly.
But let's go one step at a time.
In general, the benefits that you can get with
caching and with FusionCache in particular, I hope,
is that you will get better performance from your app
and your services will be more robust,
so things like the database going down
a little bit or being slow or stuff like that,
network issues like high-latency for some time,
think like Black Friday or stuff like that.
You can also have some benefits regarding SEO,
search engine optimization,
if you're using that on a website and we'll see later how.
In general, another thing is that it can help
you deal with things when they go south,
like again, database going down for a moment or stuff like that.
What are the main features of FusionCache?
Well, the first is probably the most interesting,
is the cache stampede prevention.
Cache stampede is a known problem in the caching space,
that happens when let's say you have 1000 requests
coming in for 'product123' like in the example on the screen.
Without any particular care about how to execute those calls,
all of those 1000 requests will go to the cache,
will not sign the data,
or will go to the database,
get back the data, save into the cache and then go on.
That is a waste of time and resources in CPU and memory because,
why go to the database 1000 times or even just check
the cache 1000 times at the same moment
for the same data, it's a waste.
What do we can do with FusionCache?
Basically the main method of FusionCache is GetOrSet,
which is a method that lets you
optimize the way to check and go to the database for data.
It is using some forms and locks and
it allows to have a guarantee that only one of
those requests will do the tricks for
the database and what not and the others
will automatically use the data that get back from database.
Looking with members of the community,
even just swapping the memory cache of.NET with FusionCache,
they told me they observe something like 40 to 60
percent less calls to
the database in typically high traffic website.
The cool thing is that you just swap it out and it works,
so you don't have to do anything in particular.
Just a quick note, the memory cache
of.NET has a method called GetOrCeate,
which is similar in the shape in the API surface,
to GetOrSet in FusionCache.
But what most people do not realize, until it's too late,
is that it is not optimized for that concurrent access.
Keep that in mind and look out for that.
The second main feature is the fail-safe.
>> That is a feature that basically
tells fusion cache A. Cache something for five minutes,
for example, or two minutes like in example.
But when it did expires,
go to the database to get a new piece of data.
But if something bad happens,
like your database is known,
you can reuse the old version for a little bit more time.
Usually, with the normal cache,
does not have Fail-Safe mechanism.
What happens is that when the data is expired,
is gone for good, it's over.
The only thing you can do in front of
an elephant database is that
you can only bubble up the error to the user.
From an end-user perspective,
that's not really the best thing.
If you consider that you've sketched something for two minutes,
is it really that bad to reuse that data for two minutes
and 30 seconds, maybe. Probably not.
Most of the times it is not.
Fail-Safe does that if you enable it and you can
enable every one of the options that we will see, both globally,
like a default and per single calls who you can have
a very granular way to configure a fusion caching its usage.
You can say A,
if something bad happens, well you refresh your data,
just use the old one for a little bit more
and you can configure for
how much time that data would be
reused and then check against the database.
Up until how much time at all,
completely you can reuse some data that is at stale.
You can have that control.
Also the title is an homage to '60s movie by simulating them,
which I suggest everyone to look at because it's very beautiful.
Another interesting thing is that a lot of times,
the real world is not just on and off,
is not like black and white.
It should have grazed so the database is
not always there and it's not completely unreachable.
Sometimes it's just as low.
Why? Because maybe you have a purist
that we take 500 milliseconds,
but maybe you are in black Friday or stuff
like that and it is a little bit overload.
That moment, you will not have a query that fails,
but you will have a query that maybe takes more time than usual.
In that regard with
so far timeouts management that fusion cache provides.
You can say something like hey,
if the query is taking more than 100 milliseconds,
like in the example,
just reuse temporarily the old value.
That means that it is literally the same as before.
But as I said before, don't Fail-Safe,
but with a difference then that here the query is not failed.
It can go in the background.
That is what I said a little below background factory completion,
the query will be put in the background, will go on.
When the data will go back and we came back from database,
you will automatically update the cache so you can
get basically the best of both worlds.
You can have fresh data as soon as possible,
but very fast response times
just by using a piece of database that's old,
but maybe not that old.
Here's when it kicks in
the SEO optimization that I talked about before.
Because with Google, for example,
we have core web vitals,
which are a set of metrics that Google use to see how
our pages are good or bad related to SEO ranking.
Two web vitals in
particular are reverse biased and largest potential pain.
Those are basically based on top of the response time.
By using smart timeouts,
we can be sure to always have
a very fast response times while keeping the data
fresh because it will be
automatically updated as soon as possible.
Another option to consider
is the second level of cache, these totally optional,
you can use fusion cache as a normal memory cache
with the feature that I highlighted as up to now.
But you can also add an additional second layer.
That is any implementation of the common
I distributed cache interface from the document BCR.
That means that there are a ton of
them available already for you to choose.
There's Reddis Memcache,
SQL Server, Cosmos DB, MongoDB,
and they are all implementation of
a distributed cache on top of those technologies.
You simply say to fusion cache at the beginning.
It's one extra line in the initialization phase,
use these additional cash,
and that's all and you don't have to do anything
else in the rest of the code.
Another thing that you have to tell
fusion cache is what serializer to use.
I've already implemented a couple for
the community based on Jason,
but you can implement your own picker or one.
That's because the lingua franca for distribute caches is
byte arrays because they do not work with object instances.
That is why isn't it?
When we do that,
and then it's the last main features,
something that may happen is
a problem of synchronization. What do I mean?
Imagine you are in a scenario with 10 nodes.
Each node will have its own local memory cache.
It will get automatically populated and they
will talk with the distributed cache,
which is a shared state automatically.
But if you put something in the cache for five minutes
and after the first minute,
the data changes through another node,
that nobody would have the data updated.
Well, but the other nodes that
have the data in their local a cache
will be out of sync
because they don't know that the update happened.
The backplane is a vertical message bus
that sends and receives messages and it is again,
automatically managed by fusion cache.
You don't have to do anything.
It's multi provider and it basically what
it does is it sends and receives messages to say,
hey are nodes in this piece of data exchange, do your thing.
That is a way for the cache as
a whole to be completely synchronized it for free.
Currently, I've made two implementations.
One based in memory,
and that is mostly used by testing and stuff like that.
The real production one is based on radius because radius,
as it's bronchi as an internal
observe the mechanism that are used to send and receive messages.
One found on the slide that I'm done,
other small features, but I think are important to consider.
The library fusion caches is licensed under MIT,
which is very permissive and you can do
basically whatever you want with it.
Targets.Net Standard 2.0,
which means, roughly speaking,
that runs everywhere on every dotted version,
both the net framework and the new chord,
the new one 6, 7,
I already a sudden on the seven one,
that is not out yet and it works very well.
The entire PI is both available as a sync, an Async version.
Because sometimes you can use one
and then you can use the other and it's fully
available and it's not implemented only as one and the
other is on top of so it's fake,
it's fully implemented in both ways.
All the options that you can set are available as both a global,
let's call it Demo defaults.
Then you can granularly change some of those options per cops,
you have full control over that.
It natively supports dependency injection,
which is very cool in today's Internet world.
It's worth cancellation tokens.
Again, it's important to maintain high stability of your system.
It has documentation in the main repo on GitHub,
and it is fully documented bx in my comments,
which basically means that when you're coding,
you will have out while you write your piece of code.
The IntelliSense or similar technologies,
supports logging the other standard ILogger interface.
It is a set of events both high level and lower level,
to know what is happening inside of fusion cache,
you'll want to peek into that.
It's a little bit extensible via plug-in system. Thank you.
>> Awesome, thanks so much Jody.
This has been super useful.
I've personally learned a lot.
I think our viewers probably have to.
I have just a couple quick questions.
One thing I noticed is that
using cache's not yet at a Version 1.0.
Does this mean that this isn't really ready for anything in
production and you're just getting
started or what do you think about that?
>> No, that is just me being extra
cautious because this is my very first open source project.
It took sometimes for me to finally be able to say, okay,
I have something to contribute back to the community which
I've used for a lot of my career as almost everybody.
It's just me being extra cautious,
but I would say that.
It is already being used in production by a lot of
people around the world and that I work on to.
I'm talking about millions and millions of
views per day on each project.
It helped me even sustain some DDots attacks and stuff like that
because of the way it makes the application more robust.
No, definitely it's rational already.
>> Wow, that's awesome, that's great to hear.
Then one other question is,
if you're watching this show,
a lot of our viewers are running on Azure,
running SQL Server, running Azure SQL database,
Cosmos DB, etc.
Do you have any tips and tricks for folks as they're working
with databases and getting started with fusion cache.
>> Yeah. Well, if they are not already using any caching OS,
just them to take a look at that.
Even just starting with the normal memory
cache.net is a great starting point and it can
save you a lot of time in production because most of the times,
even though it depends from specific contexts,
most of the time sell other systems reuse the same data.
They handle the same data in a small amount of time.
Even if it is for a couple of seconds, for example,
something that's commonly known as micro caching,
it will be a lot better for
your system so please take a look at that.
If you are using a cache,
then you may take look a fusion cache.
Even just as whopping out memory cache,
which fusion cache you already have
cache stampede prevention that I talked about before,
and that is already a lifesaver because again,
40 to 60 percent less calls to the database.
Then I have to say that in
my experience even though I ask yourself.
It save to me at all times when things went south
with the database may be having a couple of issues differently.
Maybe the connection was not so stable or
some topology changes in the network, stuff like that.
In general, knowing that when some small things go bad,
you have your situation under control automatically.
That's really very nice.
>> Awesome. Cool. Thanks so much Jody for
coming on and explaining how fusion cache works,
how to get started, all that stuff to our viewers.
We're going to include some links in
the description where you go learn more,
see some samples, read a blog and all that good staffs.
If you like this episode,
go ahead and give it a like, leave us
a comment and let us know what you think of fusion cache.
We hope to see you next time on Data Exposed.
[MUSIC]