Introducing Amazon ElastiCache Serverless

Thanks for coming. We're gonna talk about Elasticache Service. Hopefully, that's why you're here.

As you've probably heard, we launched Elasticache Service yesterday. Peter announced it in his keynote. So I'm excited here to talk about Elasticache Service with all of you.

We'll go through a little bit about what caching is. If you're not familiar with what a cache is at all, we'll touch upon that a little bit and then we'll talk about how Elasticache Service works. We'll talk about what happens behind the scenes, what are its features.

And then we also go a little bit deeper into how we built it. We'll go deeper into how it works behind the scenes. So you get a better understanding of how it all works behind the scenes, its capabilities and so on and so forth.

My name is Abhay. I'm a product manager on the Elasticache Services team and I have Yon with me who's the software engineering manager on the team as well. And we're excited to walk you through all of this.

So before we dive into Elasticache Server, who here is familiar with what a cache is? I'm assuming most of you are given you are in an Elasticache talk. That's good.

So for those of you who may not know what a cache is just quickly, the basic definition is any hardware or software component that stores data so that it can be accessed quickly and at high speed with low latency, right? So you customers use it to accelerate application performance.

You put a cache, for example, in front of a database or in front of some other service, which may be expensive, whether expensive from a money standpoint, from a cost standpoint or from a latency standpoint, expensive to read the data. And so you want to put your most frequently accessed data into cache or a cache for that matter, right?

So usually the idea is you put your most frequently accessed data for high performance, low latency access.

Now, Elasticache is AWS's premier caching service. Who here uses Elasticache today? Alright, almost half of the group here. That's good.

So as you're aware, probably we are compatible with two open source engines, Memcached and Redis. And so customers, you know, hundreds of thousands of customers use Elasticache today to optimize performance for their applications and use Redis as a data store, right?

Redis is a pretty capable engine. We will talk about that in a second. But the basic benefit, the main reason customers use it is to increase performance, right? Anytime you've got an application which is slow or it is taking too long or you know, your reads from your database or from the underlying service is taking too long. That's when you would use a cache and customers are using Elasticache to store that data frequently in front of other databases like RDS or Aurora or DynamoDB, and so on and so forth, right?

The other reason you would use Elasticache is higher scale, right? So you can, today's databases are pretty, pretty capable, you can scale vertically horizontally, you can add reader replicas to your databases as your as your application scales as your throughput increases.

But it can get expensive, right? So if you're trying to scale, for example, a MySQL database or any relational database, it can get expensive to achieve the high scale that you want to achieve.

So caching is a good way to achieve or a cost effective way I would rather say to achieve high scale, right? Because all data is stored in memory, it is pretty, pretty low cost to access that data in terms of compute access.

So you can achieve a higher scale with Elasticache and it can be more cost effective versus trying to scale your database, right.

So those are some of the main reasons customers use Elasticache today.

Redis. I'm pretty sure most of you are familiar with Redis. Who here uses Redis? Yeah, almost all of you. Ok. That's good.

So yeah, I'll just touch briefly upon it, you know, it's a pretty popular database. It's got a very simple yet flexible and capable API, right? A lot of in memory data structures like sorted sets, hash maps, even streams, pub sub etc, right?

So pretty capable in memory engine that you can use for a variety of use cases. So it can go beyond caching, right? You don't have to just use strings and set and get commands to cache your data, but you can also use it as a data store.

People are using it for leaderboards. People are using it for streaming and pub sub type use cases and a whole bunch of others, right?

It has built in support for replication and scaling. If you're using Elasticache today, you're aware, it allows you to operate in cluster mode enabled, which is lets you operate in a multi shard cache environment.

So you can scale out add more shards as needed, add more replicas as needed and scale back in when, when the traffic is low, right?

And we touched upon the in memory data structure. So I'm not going to go deep.

Memcached is the second engine we support. It's pretty, pretty popular. Probably the second most popular after Redis, if you, if you ask me in terms of caching. And a lot of our customers use Memcached for caching as well, simply because it's a simple to use API and it's, it's really good at what it does, right? It's simple and it's fast.

So if you want a cache that is, which gives you ultrafast performance, you would use Memcached.

So let's talk about some of the some of the pain points that customers have been telling us about. That led us to invent and build Elasticache Service.

The main, the main problem customers are telling us is that capacity planning is hard, right? If you've done capacity planning or decided, you know, how much or how large of a cluster you need or how many replicas you need, etc or even which instance type to use, you know, how cumbersome it can be, right?

You usually, what customers would do is look at your, your traffic patterns that you've seen in the past and you would set up capacity enough or maybe slightly higher than the peaks that you've seen in, in the past, right?

What that does though is if you see a peak, which is higher than what you've estimated, then you will see performance impact, right? Because, you, you don't, you just don't have enough capacity.

And in most of the other scenarios, you know, during night time, during weekends, when your traffic is low, you, you're paying for capacity you're not using, right? It's just sitting there.

So you, you're essentially incurring excess costs or costs that you don't necessarily need to incur, right?

So you, you can manually adjust capacity as well as I was just talking about it earlier, you can decide that, hey, when my traffic increases, I'm gonna scale up, I'm gonna add more shards, right? Or add more read replicas.

And when traffic goes down, I'm gonna scale it back down, right? Yes, you can do that. But doing so is also difficult, right? It's not, it's not the easiest thing to do because you know, you need to know exactly when to scale.

You need to know, hey, what's the memory threshold that I hit on my cache when I want to initiate a scale out or hey, what's the compute utilization or the CPU utilization when I want to initiate a scale out? And that's not easy to do, right?

If you, if you've got, if you've got a Redis workload, let's say and you're running, you know, let's say a leaderboard, right? And you're using a sorted set and so on to run that workload knowing exactly when you want to scale in terms of the CPU threshold is hard because as your, as your requests per second or the throughput increases, your CPU may not necessarily increase linearly.

So it's hard to know exactly when to set those thresholds. So customers just generally have been telling us that capacity planning is hard, right?

Let's talk about Memcached for a second. If you if you use Memcached, you know that achieving high availability with Memcached is, is pretty cumbersome. It's not, it's not something that the Memcached engine supports out of the box, right?

So many of our customers, what they're doing is they, they essentially create two clusters and write to both at once, either using some homegrown software, sometimes using open source proxies, right? And they write to both clusters at once and if a cluster becomes unavailable, they just fail over to the other one, right?

So, but it's not, it's not something that it supports out of the box in the engine, right?

If if a node is lost, then the data is lost in Memcached, right? Because there is no built in support for replication either in Memcached.

So again, achieving high availability and even some semblance of data durability is extremely hard in Memcached, right?

And it does support scaling, right? You can always add more nodes, you can scale out and reshard. But all of that re-sharding logic, etc needs to be handled by the client, it's done on the client side, right?

So the client needs to be aware which keys live on which shard and then redistribute the data when you add a new, new node, some customers just let it restart from zero, right?

So just add a new shard and some new keys that are coming in will go to the new shard. That's that's another approach. But in general, achieving high availability with Memcached is difficult, right?

So all of these. So we went back to the board and we decided, hey, what can we do about this? Right?

We do support auto scaling today on Elasticache. You can set up rules, you can go and say hey on Friday evening at 5pm when I see a lot of my traffic scale up or scale out and on Sunday afternoon, scale back in and or you can say that hey, at a certain CPU threshold or memory threshold just scale out and scale back in when it falls below a certain threshold.

But as we discussed, it's going to be hard. It's not, it's not easy to decide those thresholds either.

So we went back and decided, hey, what, what can we do about this?

So I'm excited to introduce Elasticache Service to you today. Well, yesterday, and we, we were talking about it today.

Elasticache Service essentially gets rid of capacity planning for you completely, right. So you don't have to worry about capacity planning at all.

There is no infrastructure management. You don't choose any instance types, you don't choose the number of shards, you don't choose the number of replicas.

There's very little configuration required to create a cache, right?

So here's, here's some of the features for the cache or for Elasticache Service, right?

We've made it super simple to create a cache, right? You can create a cache in under a minute with no capacity management. As we, as we talked about earlier, you don't have to worry about deciding how much capacity you need up front.

Same performance semantics that you see on Elasticache today. And you get pay-per-use pricing.

We'll go into each of these a little bit more in detail, but really what we're trying to do is we are trying to simplify or take on more of the operational overhead and the operational burden of running a cache so that you are free to work on your application and you just have a cache that just works, right.

So at launch, Elasticache Server is going to be compatible with Redis 7.1 and with Memcached 1.6.

It supports the same microsecond performance that you are used to with Elasticache. There is a maximum limit of 5 terabytes per cache. So every cache can grow up to a maximum of 5 terabytes at launch.

And so yeah, because customers have been telling us that they just want a simpler way to get started. So we made it extremely simple.

We said, hey, all you need to give us is a name. You tell us the name of your cache and we create it for you. You don't need to give us anything else.

There's no other settings in terms of, you know, configuration or capacity and so on and so forth.

What we did was we really just took a step back and took a thoughtful approach of what levers and what configuration controls we want to offer here, right?

Because there are, there are, you know, I'm sure as developers we like to tinker, we like to have a lot of control over the underlying infrastructure and you have the capability today with Elasticache, right?

So you can go in and configure engine parameters, you can configure how many nodes you want, how many replicas, how many shards which AZs they live in? You have a lot of control with Elasticache today.

But what if you wanted to get started much more easily and I think that's the philosophy or the design philosophy behind Elasticache Service, right?

So now that doesn't mean there is no configuration options, right?

So we had to decide for each option. Is this something that as developers, is this something that customers would want to do or need control over?

So basic things like, hey, which VPC does the cache operate in? Right? In terms of security, that's obviously something you will want to control.

So you can choose which VPC is the cache accessible from. You can choose which availability zones you want access it from.

So if you've got an application that lives in, let's say AZ A and AZ B, you want to access the cache from those AZs, right? You don't want your cache to live in AZ C because you will be incurring latency with cross AZ hops.

So by default, we will pick, you know, two availability zones in your default VPC if you don't specify them, but you always have the capability to go in and specify exactly which availability zones you want to access the cache from.

Things like encryption is always on by default, right? So encryption and transit encryption at rest for backups is always on by default.

And but you can choose if which key you want to use for encryption. So you can choose, for example, to use the service managed key by default or you can use a customer managed key.

Ok. So the biggest benefit I think with Service is just no capacity planning. We've we debated you know how to simplify management of capacity. What levers do we give? But I think at the end where we landed was we just wanted to get rid of capacity planning completely, right?

So what this means is Elasticache will scale vertically and horizontally for you and it automatically meets the traffic demands that you throw at it, right?

You're not at any point configuring how much capacity the cache has, right? You don't have to worry about that at all.

Elasticache Service is constantly monitoring the memory, network and compute utilization on your cache and it uses what we're calling predictive algorithms to predict where your traffic is going in the next few minutes to scale appropriately.

And the way it works is as it says, we scale both vertically and horizontally. So what that means is say you're operating at, you know, 50,000 requests per second and suddenly you see a spike.

We will let the application scale up in place, right? So it will, you can, you can take on spikes and scale up in place while we in parallel, we decide to scale out ahead of time, right?

So and as you know, scale out operations can take time, you sometimes of the order of single digit minutes, right? 5 or 10 minutes it can take to scale out.

So we decide to scale out early while letting the application scale up in place so that you have just the right capacity when you need it.

We decided to give you pay-per-use pricing, right? You don't pay for capacity at any given time. You're not paying for the capacity that is behind the cache you're paying for your actual use.

You're paying for the amount of data you store that is built in GB hours and you're paying for your requests that you execute on the cache in a new unit called Elastic Cache Processing Units, right? So you can think of ECPU as a measure of the amount of compute and network throughput that your application is consuming or your requests are consuming.

The simplest way to think of the ECPU is let's say you're running a simple caching workload, right? You're using Redis strings, set and get commands. So every set and get command that transfers up to one KB of data will consume one ECPU, right? If you have a command that transfers 2.3 KB of data, it will consume 2.3 ECPUS, right? It will calculate the amount of ECPUs based on the data or the network data transferred.

Some commands as we discussed on Redis can take up more CPU time as well. So let's say, taking the same example, let's say you're running leaderboards, right? And you're running give me the top three items in my sorted set, right? So now depending on the size of your sorted set, depending on the amount of data that is being accessed in your cache, the amount of CPU time taken can vary, right?

What we do is we actually measure the total CPU time taken by your command. And we compare it to a simple set or get and we essentially charge you in multiples of that, right? So if it's taking five times the CPU time of a simple set or get you will, it will charge you five ECPUs, right?

By default, you get four 9s availability SLA on every cache. Behind the scenes, we are replicating your data to multiple AZs at once. It's not something you configure, it's not something you have to worry about, it's just there. You can just get four nines availability SLA by default on every cache as we discussed, encryption is always on in transit as well as at rest.

We also support a lot of the compliances that ElastiCache already has today including PCI, SOC and HIPAA. So if you're running a workload which needs these compliances, it's ready to be used on ElastiCache as well.

Let's talk about another benefit. I think this one is an interesting one. We built, as we were talking about scaling earlier, right? It is scale when the cache scales. What happens behind the scenes as you probably know is when you're scaling out, we add new shards, right? So we're gonna add a new node, we might add new replicas if you have replicas in your shards and then we rebalance data, right? So your data is moved from one shard to the other.

And when the new node becomes available, then the Redis client or the Memcached client for that matter has to discover the new topology, right? So most open source Redis clients are able to discover changes in topology and they reconnect to the individual nodes. And when a new node becomes available, they just connect to the new node and start executing commands there sometimes.

But this configuration and depending on which client you're using sometimes this can also result in availability issues because we've seen issues, we've seen cases where clients continue connecting to the old node and you see an availability impact because it did not correctly rediscover cluster topology or so on and so forth, right?

So what we've done is we've created a simple endpoint experience. You get a single endpoint to connect to from the client's perspective, you're talking to a single node, you're not talking to multiple nodes at once. So now the client doesn't need to worry about cluster topology discovery at all.

The way we achieve this is through a new proxy layer and we'll talk about that a little bit more in detail. There's a new proxy layer which is a network load balanced fleet of proxy nodes that handles all incoming connections from your clients, right? So your client is connecting to the proxy node and then the proxy executes the commands on the online cache nodes.

And what that means is now, if a node becomes unavailable for whatever reason, whether it's scaling out whether it's just, you know, the EC2 instance is lost for whatever reason. And a new node is being brought in. The application of the client doesn't need to know about it. They don't, it doesn't need to care about it because you're talking about the cache proxy and the proxy automatically rediscovers the cluster topology establishes a new connection and executes the commands there. So there's no availability impact that you might see.

You get a much smoother curve on the availability semantics that you see on the ElastiCache service versus a instance based cache, some performance numbers to share. We will see the same sub millisecond performance in terms of reads when using read from replica. We do support reading from replica semantics for both Redis and Memcached.

Use rights are slightly higher at 1119 100 microseconds at P50 you can scale up to millions of requests per second. And up to five terabytes of data as we discussed earlier on each cache.

So I'm sure you're curious about how all of this works behind the hood. So let's go a little bit deeper. We'll talk about the architecture, we'll talk about how we achieved. And the trade off we made and hopefully you'll have a better understanding of how it works, what the capabilities are and Neuron is going to walk us through all of that.

When we designed the system, we had to answer multiple different questions and one of them was how can we actually serve a customer who has spiky workloads multiple times an hour and still providing him a seamless scaling experience.

So let's understand how the scaling is actually working on the scaling. We have three main stages. The first one is the detection and the detection is happening within a second. So we can actually meet the customer demands. We also have the ability to project the future demand by monitoring the usage pattern. So we can assume what is going to be, what we're going to be the next few minutes, the usage of the customers, this give us the power to be more proactive and to scale our capacity out of time.

So once the workload kicks in, we already scale out and we have enough resources to ingest the new data. Now, the second phase is provisioning and the provisioning is done within a minute and we can do that thanks to a warm pooling mechanism that we build. And the warm pooling is a list of cache engine nodes waiting in a standby mode and ready to be attached to existing cluster.

So once we decide that we need to scale out, we can use this war pooling, attach the cluster and do it very quickly. And the last phase is data rebalancing. Now, the data rebalancing is happening in parallel between the slots of the data that we have across the shards. So we can actually move slots of data for in parallel at the same time from different shards. And this is help us to expedite the process.

How we do that, how we choose which of the slots needs to be migrated. We are monitoring the usage at per slot level and then we determine which of the slot candidates to be migrated to different shards. We can mark them as hot or cold or anything that we think that this is the right time to start moving them to a different shard.

So eventually what is happening is that we yield with a balanced workload across the cluster shards. Now, we also took the decision to scale when we reach 250% of the resource users usage. And the reason for that is to allow us to handle increased capacity of up to two times and still to complete the scaling process successfully.

Horizontal scaling involved with moving data from one shard to another shard. And usually this is a long and heavy process and we had to invest and to improve it. So we can actually improve the scaling performance.

We did multiple things. One of them, it was to develop build a batching mechanism so we can move bulk of data. That will help us to expedite the data migration and to support that we increase the network buffer. So we can actually process more data on the source and on the target upon every system called that we are executing.

And in addition to that on the networking layer, we are now able to reuse the open connections and we don't need to reopen every connection every time that we are moving a new slots. So this is also improved significantly the replicated data.

And last, we took the batching mechanism that I mentioned before. And now it's running in parallel to the purge process. So compared to the previous state where we had to replicate all the data and run the purge process, now we can do that in parallel. So overall we this all these improvements, improve significantly the replication, the slot migration data, the repetition process and we benefit from a better scaling performance.

Now, I want to talk about Caspian and ElastiCache. So first ElastiCache built on top of a Caspian platform. And for those of you who missed Peter's keynote where we talk about Caspian, I will give a brief about that.

So Caspian is a new type of Amazon EC2 instance that it's purpose built for dynamic resizing and it can do that very quickly. So Caspian platform do not have a fixed memory or CPU footprint and can be rescale up and down very easily. And so Caspian deliver a very good performance without compromising on the cost. And they do that thanks to an oversubscription techniques.

Now, the comparative of a subscription techniques is where tenants are assigned more resources than actually exist on the physical hosts. And this is largely work when the level of the usage of the resources is below than the level of the physical resources. But sometimes this is not the situation and we can find ourselves that the tenants want to use much more resources than we have on the physical host. And we need to start thinking how we can move them from one Caspian platform to a new to a new Caspian platform. And I will speak about that, how we do that in the next few slides.

Now, how we actually benefit from all the good things that Caspian provide us. So first Caspian allow us to instantly grow our and shrink our compute in place. So we can benefit from more additional resources of CPU memory and network bandwidth. While then the more workload that kicks in and when the data need to be repetition and we need to rescale, it actually provide us the capability to start with vertical scaling and to follow with the horizontal scaling. And this is a big achievement.

Now, with all this Caspian, we still need to maintain them and to monitor them so we can manage them correctly. So we can make sure that in our fleet, we have enough resources to handle the current usage of the workloads and the future.

So let's understand more how we actually managing all these Caspian. So we are utilizing the underlying capacity of our Caspian platform and we do that according to the customer demands. And the main challenge here is to ensure that all the cache nodes that running on the Caspian has enough resources to manage the existing workload. And the one that future to come to the system.

So we need to make sure that we have enough resources, enough. We are not running out of resources or CPU or network bandwidth. Otherwise, the cache nodes will be, uh, experience with reduced throughput and increased latency. And this is something that we definitely want to avoid.

So for that, we build a live aggregated view of all the king platform and we do that using async polling mechanism that run every few seconds. And then we build a live aggregated view of all our fleet. With this aggregated view, we are able to determine which of the casing platform is considered as hot and which of them is not.

And then we can run a heat balancing on that particular caspian and to decide which of the cache nodes we want to migrate to a different caspian platform. Now, this helps us to keep all the customer platform uh fleet healthy with enough resources to handle the workloads of our customers.

Now I mentioned very briefly that we're running the heat balancing, but let's understand more deeply how it's actually working. How what is the algorithm that we use to decide which of the cache nodes need to be migrated to different caspian. So we call it, we call it heat management. And the way it works is like that when we are searching for uh a cash node to be migrated to uh uh a new um caspian. We are searching for the second hottest node in terms of resource consumption.

And the reason for that is that the first hot node is probably going under a heavy load and um is busy with ingesting the data. And there is also good probability that it is going under scaling process. So it's better for us to leave it, let it complete the, the process and, and, and, and not interrupt him in the middle. And for that, it's, but still we need to find uh uh a cash. No, that use significant resources that once we finish the eviction, it will free up on that caspian. And uh uh uh otherwise we just move in a cache node between the caspian platforms. So this is the reason why we choose the second one.

Now, when we are searching for a new placement for a node, we are um using the algorithm that called uh uh the power of two random choices where we are picking two random caspian nodes uh uh platforms. And um we are uh choosing the second hottest caspian uh between the two. This is uh help us to uh spread the balance evenly across our fleet. And it also works really, really well uh using um in, in delayed, delayed data on, on fail over situations.

Now, on top of these two things, we also build a noisy neighbor isolation and a smart management uh resources. So we can make sure that the tenant inside the pla uh c platform does not interrupt each other. We do the things to um uh we use the linux c group to isolate the usage of the uh cpu. And for the memory, we use the linux hot plug and hot unplug to decrease and increase the allocated all the the physical allocated memory that assigned to each of the um cache nodes.

Now, I want to talk about different angle uh of uh the servius elastica cus and this is connectivity. And as you can see, i'm speaking about single endpoint. So we decided to build uh a single logical entering point to elastica cus. And for that, we build a new elastica cus proxy and that enable us actually to encapsulate uh and to track all the cluster topology changes behind the scene.

So anything related to scaling fail over connection disconnection, uh a patching that's happened behind the scenes, it's hidden from the client. And this is a huge improvement uh uh compared to uh uh uh the node based provision. So we build the proxy to be highly performance, highly available, fast and secure. And we decided to build it using r language. And the reason for that because we want to leverage the inherent features such as memory, memory safety, concurrency safety and high speed.

Now, the proxy uh main job is to out client request to the correct child while uh um uh while supporting a huge scale of possibly hundreds of childs behind the scene while requiring for the client to maintain only a single connection. That's it, the client can maintain only single connection while the proxy can support thousands of connections behind the scenes. And this is uh uh a great benefits because it takes away from the client all the responsibility to deal with all the connectivity aspect to the cluster shards.

Now, we might think that for every established connection to the proxy, the proxy will establish a connection to the cache nodes. And so this is can walk up to some level of uh of connection number of connection. But when we are talking about high scale high number of connection, we have to think about different solution. So for that, we build uh a new multiplexing solution which opened a single tcp channel uh to pass multiple different client connection and the unique multiplexing protocol uh increased the command processing by over 3.5 times um and reduced the number of open connections by collocating several commands and response on the same network packets. So that makes the proxy very fast, lightweight and uh uh more reliable.

Now, uh elastica servers provide high availability um by distributing both cache nodes and proxy nodes across multiple different phases. So that even a, a full a fernel will not impact the availability and to avoid not, i'm sorry to uh uh provide low latency. Clients are routed to the proxy in their own a z. So they can achieve uh sub millisecond latency and, and, and, and we do that. Thanks to r 53 local a z uh capability.

Now, there is a good chance that the proxy will route the request to a different where the cache nodes is located there. And, and the, we, we have a solution for that and the, the solution is to use the reform replica option. Now, if we are sensitive to latency, we can use that. And the proxy will detect the uh option that we want to use the reform replica. And we'll make sure that it will route all the requests to the same ac where the application is located. So all the process will be on the same a z so we can achieve the sub millisecond latency.

Now, let's talk about reform replica. Our recommendation and the best practice is to use the reform replica option. Um the proxy as i mentioned before also for the replica will provide a single entry point to manage all the connectivity to the replica. It will encapsulate all the connectivity to the replica and there is nothing to handle on that on the client side beside of just turning on the uh r from replica option.

So the proxy will prioritize always to read from the local regardless if it's a replica or primary node. And if the replica is busy now with syncing the data. So no worries, the proxy will choose a different node uh for seamless experience. Now, there is no need to configure as i mentioned before. Uh nothing on the server side. Everything is done automatically on the server side. We just need to turn on the uh option that we have on the client side, same as you see here in the code.

So let's go through the code and i will explain what we see here. We have a python code that connects to um elastica servers for redis. This is a python code for redis. And what we can see here, we see a single entry point, single address that connect to elastica servers. We construct it in the redis client and we ask to use two options to use the ssl and we want to use the reform applica option.

Now we have two block of of cards. One is a fall loop. The second one is a pipeline where in the fall loop, we are just receiving the values. And in the in the pipeline, we batch four keys on the same time. What is beautiful here is that we are offloading all the complexity of the connectivity to the proxy. You will make sure to connect to the right child, you will make sure that um uh uh he, he will choose the local availability zone to achieve the five milliseconds latency. And there is nothing that we need to do in the server side to um to handle that.

Now, same as for this elastica servers for mkd offer as well. The option to read performance uh using reader end point, all the right operation will continue to function as uh as usual. But the red operation will run to the local a for uh better performance to achieve the family second latency.

So both examples that i show uh are very popular in caching patterns where we want to achieve a sub millisecond latency. So what we see still here is so i walk through multiple diff different uh technical problems that we have to solve in this project. Of course, this is not all the story if you still want to catch up with me. I'm here at the red event tomorrow. We have a light talk. Uh we are presenting a demo so you can join us.

Um and i uh hope you enjoyed, i will call to abe to continue. Thank you, everybody. Thanks iran. So hopefully that was uh useful. And uh you got an insight into how uh you know, things are built behind the scenes. Uh you know, so elastic css is live. Uh we have customers using it today.

Um you know, uh it's as you know, uh all the core benefits, right? Just to recap you, you a pretty significant simplicity of cash operations, right? You can set up a cash and operate a cash at, at, you know, at high scale applications without any configuration and so on, you get uh you know, fast scaling, we can accommodate workloads as they grow and shrink and you get paper use pricing.

So you don't have to worry about paying for capacity at any point, right. So you're always paying for the actual usage. So some of our, i think an interesting question, some of our customers have asked us, you know, hey, when does it scale back in? And the answer is it doesn't matter, right? Because you, you're only always paying for use, you're never ever paying for capacity.

So it doesn't matter when we decide to scale in. It's uh it's purely a cost optimization thing for us internally. It doesn't uh we will always make sure that there is enough uh resources available for your workload uh as it scales, right?

So you can get started today. I encourage all of you as, as we discussed. It's as easy as giving us a cache name. Go into the console, give us a name, get a cash in point, plug it into your client or mem cache client.

Um so here's, here's a url for where you can learn more about uh about cus uh all the features that we discussed.

Um and i hope you uh uh you know, try it out today. Um we can, i think we have about 15 minutes or so. So we can open it up some questions. I'm sure you guys have some, uh, maybe we'll start here.