JetStream KV: A fascinating alternative to Redis...

you're most likely to be using a key

Value Store of some sort inside of your

system or application and you're

probably using something like redis and

for good reason redis is really easy to

operate it has some great features and

most of all it's really really fast but

what if I told you that there was

another viable key Value Store available

to you that really kind of Rivals Reedus

in terms of performance but also offers

some considerable advantages when it

comes to things like security

multi-tenancy and G distribution today I

want to talk all about Nat's jet

stream's key value stores and how they

were designed from the ground up with

distribution in mind and why they may be

a really good solution for your

distributed system so let's get straight

into

[Applause]

[Music]

it but before we do be sure to click

that like And subscribe button and hey

share this video with a friend or

colleague I'm sure they would really

enjoy it okay on with the show so we've

been talking all about Nat jet stream in

this series and if you haven't caught up

on videos we have a really cool series

that talks all about Nat's jet streams

design and um how it can help benefit

you to just learn more about some of its

design aspects um but one of the really

cool things about being able to kind of

solve for streams and persistence and

have this globally ordered set of

messages that are indexed on subjects or

topics is that you're able to create a

lot of these really neat abstractions on

top of without a lot of effort and

that's really how jet streams key value

stores were born um we saw that we were

you know handling streaming really

really well um but that with just a

little bit of effort and maybe a little

bit of kind of client sugar you can

create these like real key value stores

to rival things like redus um or Dynamo

or things like that um so really quick

um how does a key Value Store actually

work in in jet stream well at its base

layer a key value store is no different

than a stream in terms of all of kind of

the internals and how they work there's

really just some syntatic sugar and a

couple um a couple functions or uh API

calls that are used to really kind of

support the KV use case well but under

the hood it's using all the internal

Machinery um that a Nat jet stream

stream would and so you can kind of take

a lot of the parallels that we learned

all the kind of topics that we learned

about streams and apply these to KV and

how they apply for that particular

access pattern and so at its core you

have a KV bucket which is just a stream

under the h

and then you have these Keys which are

represented as subjects I have food. bar

and bat. baz um but one of the really

neat things about this is uh these are

all just messages and subjects that are

being stored in a stream under the hood

um and so each you know particular key

has a value associated with it but not

just a value we actually have full

history of these values that you can um

that you can have and you could set on a

per bucket basis how much history you

want um but you can essentially have

historical values that you can kind of

whip through um for for your particular

use case if you need it um which I think

is just a really really neat feature um

and these are all kind of decided by

revision so you see revision 4321

revision 765 um these are kind of

globally ordered on a bucket level um

but you can kind of use revisions in

some really interesting ways uh like you

know optimistic and currency control and

stuff like that um and so at its very

very core the key Value Store access

patterns are very simple you can get you

can you know update you can you know

create uh various keys and I'm going to

go over all these operations and and how

they work um so what is a key Value

Store kind of good for well it's good

for storing filtering and retrieving

that stuff that kind of can identify as

key value pairs you want to index on a

particular key and you want to throw a

blob of data whether that's a Json

object or whatever um inside that

particular value and so very very

suitable for things with that type of

access pattern um the NAT key value

stores gives you history so you can kind

of use that as another dimension um you

know when writing your applications and

and lean on that for um some of the

heavy lifting you can also because it's

a stream under the hood we have a kind

of watch mechanism where you can watch

for changes to a key we have many many

companies that are using gats that are

kind of using these key value stores as

a as a big kind of like configuration

management layer where you could you

know set config variables or or things

like that in that key value store and

instead of your applications having to

pull for those or for you having to

restart your application to get those

variables you can just have them watch

for changes and automatically update you

know immediately and so I think that's

something that's really really neat

about um about key value stores that you

could watch for changes like I mentioned

before we also have optimistic

concurrency control which we will cover

in an example today doing a leadership

election system I know that sounds

really complicated but I promise it's

not it's going to be very simple um but

optimistic concurrency control is

basically some mechanisms there for you

to make sure that clients aren't

stomping on each other when you have a

key value store and you have multiple

kind of concurrent writers you want want

to make sure that if you're kind of like

updating that Json payload and saving it

back to the database that you're not

kind of conflicting with one another and

so optimistic concurrency controls great

for that and we'll go into what

operations support it lastly it wouldn't

really be a very functional key value

store if you didn't have some form of

TTL or expiry so whether you're kind of

building like a cach mechanism or you

need to use ttls for kind of other kinds

of things um we have that on a bucket

you know level where you can set a TTL

for an entire key value bucket um in a

future uh you know update to the server

we're going to be supporting um per key

ttls which is going to be amazing and

I'll cover all the other really cool

features we have so many coming down the

pipe for uh key value that's just going

to make it an excellent excellent choice

for for keyue stores for pretty much

anything um and again just a reminder

that a key value store for Nats is just

a stream so you get all the really neat

things that come with Nats jet stream

the global scale the replication being

able to mirror source mck and demu these

things and you get all the multi-tenancy

of with accounts U multiple buckets and

you get all the security and ACLS that

you need there so um we we see a lot of

organizations and uh folks writing

applications with this taking advantage

of all these features because they're

kind of harder to get in other um you

know in other key value stores and so

just keep in mind that um as we're

talking about KV stores they're not much

different from streams under the hood

they just have a little layer of you

know I would say sugar on top of

them so let's address the elephant in

the roof though I started out talking

about redis kind of being this king of

key value stores and it really is it's a

great piece of software I have no Faults

for it um so why would somebody use gats

over reddis well that's ultimately going

to depend on what you need um redus is

great for standing up something it has

great single node performance it has

great kind of rep replication

performance and everything like that but

they've T redus has kind of taken a

different approach to um especially on

the infrastructure side that that then

Nats has and so you might see some

advantages you know um when it comes to

kind of like global scale you know

moving out to a super cluster instead of

just a cluster inside of a single uh

data center or region um you might find

some advantages there and I generally

hate doing benchmarks it's not I'm not a

fan of doing General benchmarks because

they can go completely astray and it's

hard to do a real Apples to Apples uh

comparison but I've had many folks ask

me can we just have some sort of

comparison and the goal here is not to

say who's better at what um more to say

that we I think we can all agree Reedus

is a Fant fantastic piece of software

and it's really fast and it meets a lot

of those needs and what I wanted to show

here is that uh Jetstream you know KV is

also just very comparable in terms of

performance um characteristics here now

if I were to get into how these things

um you know do replication and

clustering and everything it would it

would turn from an Apples to Apples

comparison to an apples and oranges

comparison um because they are they they

start diverging very quickly here but

for single node right performance you

can kind of see uh redus is going to win

out on the latency side especially for

for a small number of writers and and

jet streams KV is going to kind of have

a a larger kind of sealing in terms of

handling concurrent requests and and

scaling those out um in terms of

throughput and so um but ultimately

these are all very comparable I don't

think we're going to see like this thing

is 10x faster than than the other one um

so so if you're if you're really a big

fan of redus and you want kind of

similar performance characteristics here

um you know Nat's jet stream is going to

be a really really kind of good choice

for for you so to talk about um we

already talked about how all streams are

configured and many of those options um

can be shared for uh for KVs um the the

three kind of Concepts I wanted to just

address really quickly that's new to KVs

is the idea of history of ttls and

compression and these kind of exist in

some shape or form depending on how you

you know configure your streams um but

these are kind of newer concepts for a

Nat KV this idea that you can have mult

multiple values for a key and that they

could be historically ordered um is an

excellent Advantage for a lot of

applications the fact that you can set a

TTL and those would expire and fall off

and then you have um a compression flag

that you can kind of condense and

compress um your your key Value Store um

which is

awesome but we're going to jump into the

meat of it and I'm going to talk about

all the operations that um kind of come

with this key value store some of these

are going to seem super simple and

obvious but I wanted to talk about some

of the subtleties behind them and how

you can leverage them for your

applications now we're not going to have

all of the operations that redus has

we're we're just not going to have all

of that those features and functionality

edits core anat key Value Store um right

now is kind of dumb when it comes to the

types of values that you put into that

value slot uh but we have some upcoming

features that are going to introduce

some more um value-based semantics and

I'll talk about those in a sec uh but

quite simply you have a put operation

which is basically just saying I want to

set this key orders1 234 for I give it a

payload and the key Value Store accepts

it says cool you've written it um the

key value store is going to return a

revision number which we'll we we'll be

using um and our examples for um some

cool stuff like optimistic concurrency

control but it's just very easy to you

know in any sort of gats SDK whatever

language you're using to execute a put

command against this KV

store then we have the get command which

is again just a simple as a put command

you get an order and uh and it's going

to return that order to you with the

subject any sort of headers and metadata

as well as the payload um and it's going

to get the the most recent value to you

now you can request a specific revision

as well if you know that you know

there's a revision that that in

particular that you want from a

historical value you can request that as

well via the get

command then we get a little bit more

subtle um and we start getting into kind

of our OCC or optimistic and currency

control um layers here which is uh the

create command so the create command

will will um essentially let you create

a key and like many systems it will fail

if that key already exists and this is

really important because um we can we

can use this in combination with ttls to

do very cool things like leadership

elections um you know distributed locks

and Lease systems and and I'm going to

demonstrate that in an example here

today uh but just know that if you use

the create command it's going to fail if

you're going to if if that key already

does exist um but it can be combined

with things like ttls to make for some

really really neat patterns very similar

to create as well we have the update

command which allows you to try to

update a value but you have to specify a

revision number um of what you think the

last known revision is and this is used

when you have multiple clients that are

all trying to update the same key to

ensure that um they will you know not

stomp on each other so imagine that

client a you know sends an update to

orders maybe they changed one of the

fields inside of this Json um payload

and they said the last known revision to

me is revision number 20 121 KV store

says cool we got it um you are now on

revision 122 which is great um and then

a second later or even you know

milliseconds later client B um says I

want to update the the order 1 two 3 4

um and my last known revision is

revision 121 um and the KB store is

going to reject that because it knows

it's had a a later revision and it's

going to tell the client hey I can't do

that um so the client can then get the

latest version and do its patch or

whatever it needs to do update its

column um and then send an update to the

KV and it will succeed and so update and

create are really cool kind of

Primitives to use here or commands to

use here for the KV um to make sure that

clients aren't stomping on each other

but also you can express a lot of really

cool kind of locking uh mechanisms

here and then we get to delete so the

cool part about delete is because KV was

designed for historical values in mind a

delete actually does not delete the data

itself but instead puts a delete marker

as the latest revision for that

particular key um and so it would you

know not return a payload for you would

say that this thing is deleted um even

when you kind of do a a particular watch

and you're W you could see that you know

Keys have been deleted as part of the

notification which is really neat and so

um a delete is kind of like a soft

delete for for a KV um and it allows you

to still have access to all those

historical values which is really nice

and then Purge is kind of like your more

destructive action for a delete um it's

going to insert that delete marker so

you still get any notifications and

Watchers all still work well which is

what you want um but then it's going to

uh it's going to delete all of the

revisions before it in that particular

key space um and so uh you can also

specify um in a in a delete you can

specify an optional revision just to

make sure um that you don't kind of bump

up against any issues in terms of uh

deleting the wrong Vision or anything

like that so you also have optimistic

and currency control Primitives here

inside of delete um so those are kind of

the deletion commands um and then we

kind of move on to the other command and

this is more of a kind of a less of a

command and more of uh a way that the

client libraries all work um but you're

going to see this in your sdks which is

watch and this is one of my favorite

Parts about the KB because it gives you

kind of this live update key Value Store

uh you could use it for all kinds of

things whether you're maintaining an in

memory cash or whether you're you just

want to kind of get the latest updates

as soon as possible you want to remove

polling as an option um this is going to

uh be what you want to use for that um

and so under the hood what this actually

does and you could look at my previous

videos for how all this stuff works

under the hood but um this is going to

create a lightweight consumer to be able

to uh to be able to get all of the

notifications for that particular watch

and so you get a lot of the same

features that consumers do like being

able to filter on a particular subject

and so maybe I don't want to watch all

the keys in this key value store this

can be a massive key value store we have

people that put millions and millions

and millions of keys um tens of millions

uh hundreds of millions of keys inside

of a key Value Store um and so maybe you

don't want to access all of them so you

could use subject filtering to filter on

that particular um set of keys you can

also uh use filtering to decide what

kind of uh notifications do you want do

you want to get the history of each of

these keys or do you want to just get

the latest value do you want to receive

delete notification

um do you want to be able to receive uh

you know updates and and metadata only

um there's a lot of really neat things

that you could do to kind of choose just

like we talked about in our consumer

video to choose what kind of gets sent

over the wire so you could remain really

efficient and then lastly you could also

kind of choose where do you want to pick

up on what kind of revision do you want

to kind of pick up from um because you

might not want to get all of the values

and so what this does is you're going to

uh create a a Watcher in your client SDK

and um and then the KV is going to

continually send messages um and what

it's going to first do is it's going to

send all of the current values and it's

going to send a message that's

essentially blank to signify that it's

uh it sent you all the most recent or

what it knows is is the most up-to-date

values and from there on you're going to

start receiving notifications of updates

and so you could decide if you want to

just look at all of the values real

quick you could just like watch and get

all the current values and then stop it

or you can just keep it going and

receive any sort of update delete create

notifications for that particular key

space so watching is just a it's an

excellent tool I use it all of the time

um and it's it's a really really kind of

unique feature to the Nats

KV okay let's talk really briefly about

replication because I think this is

really important I know I talked a bit

about replication when it came to

streams um and and all of these kind of

features and functionality are shared

between streams and KBS and object

stores but I wanted to point out you

know replication for KVs in general um

you can obviously do your um R you know

n replication um where you can say I

want this to be you know replica of one

or or three or five um and that exists

within a single region right it will

exist within a single cluster um for the

most part so on uswest 2 I have an R3

and this is great for durability

purposes right Nats will handle all of

the uh consensus um you know it will

handle the raft group and all of the

Machinery under that and you could just

kind of um know that your knots KV store

is going to uh you know stay durable you

can take one node down and still accept

rights um you can take two nodes down

and still accept reads etc

etc and then in terms of kind of

advancing the way that our replication

works if you want to go outside of a

data center or you want to go through a

leaf node or into another region this is

where mirroring and sourcing come into

play so let's cover mirroring for a

second um let's imagine that um we're

we're using that Us West um you know key

Value Store over here we might have a

replication factor of three like we had

in our previous example but we want to

have a readon replica um available to it

um you know in another region uh maybe

we want to be able to sync kind of this

data and we just want really quick

access to rights and so we don't want to

Ping pack ping pong all the way back

over to um to the west coast of the US

especially if our application is running

over here on the east coast and so what

we could do is we could create a mirror

and the really really cool part about

all of this is when you create a mirror

for a key Value Store Nat is smart

enough to serve up requests from the

closest mirror and so you don't have to

change anything in your particular

applications and I'm going to show you

this today it's so cool because you just

create a mirror and then all of a sudden

your latencies go down um so it's

automatically going to be a read replica

um but it's also going to De delegate

rights you don't have to think about who

you're talking to um you just say I want

to write to this key value store and all

of the rights are going to go through

the leader um which is going to be over

here and so you can do this as many

times as you want and mirror all around

the world and have a very fast um you

know durable consistent key Value Store

um available to you and so this is this

is just really neat um this is usually

really hard to do in a lot of other

Technologies and uh Nats makes this so

so easy the kind of uh I would say the

third version of replication here would

be sourcing and sourcing isn't quite um

you know like a digital twin like a like

a mirror is but instead it's a about

kind of mxing and demoing data and so um

let's talk about demoing first so

demoing is this idea of like I have a

big key Value Store maybe somewhere in

central us or somewhere centralized a

huge key value store with a bunch of

data into it and maybe I'm going out to

the edge or maybe I I have like all of

these values separated by a region and

so it makes sense to have more Regional

Edge placements of these for for latency

purposes what I could do is I can create

a bunch of other little key value stores

and I can Source um all of this data and

just filter on the stuff that I care

about so this could be a big huge key

value stores and these can be much

smaller key value stores that only care

about the data that they need to and

whether you're being distributed like

geographically or you're being

distributed organizationally where you

might have different business units that

care about different sets of data you

can still have a big key value store

that then gets demoed into smaller ones

for you know those purposes um and

that's really really neat and so you can

source and you can filter on the larger

data set into smaller key value stores

that live uh maybe closer to the

applications that are calling them the

inverse of this is going to be um mxing

which is saying maybe I have a a bunch

of key value stores that uh exist uh you

know all over the world in different

Edge locations maybe these are running

on little raspberry pies I don't know um

but I want to be able to take those and

I want to be able to sync them into like

one large key Value Store um in the

cloud somewhere and this is where kind

of M sourcing comes in where I can take

um each of those kind of regional keys

and I could MX them all into um a single

one and one of the cool one of the cool

things that um recently came with theat

servers you can now do remapping as soon

as you're kind of sourcing into these

streams you can say hey you know the key

space might look like one particular

thing for this key value store but I'm

going to remap it into something that's

more appropriate for this key value

store and you can do all of that you

know all that all of that is

configuration based um inside of gats

when doing sourcing and so really really

cool feature I wish I had time to cover

it but I think it's going to be a whole

separate video to cover how to do this

in depth um but it you know feel free to

read the docs try it out for yourself

it's a really cool pattern and many

folks are kind of taking advantage of

that um before we dive into the examples

I would just want to talk quickly about

some upcoming features because uh it's

funny that I'm doing this key Value

Store video um right as we're about to

release some really cool features for it

the next version of nat server is going

to include a lot of these things um

value based semantics like counters

lists sets Maps things that you would

expect to be in kind of a value based

key Value Store um and stuff that you

might miss from reddis all of these

Basics are going to now exist inside of

the Nats KV which will be great um like

I mentioned before we're also going to

be getting per key uh ttls which means I

can have a particular subject or key and

I can say here's how I want it to expire

and um and you could do that you know

have variability across an entire bucket

um which is really useful for things

like building like toy schedulers or um

if you want to build your own version of

kubernetes or something like that you do

all of that um you know much easier with

a per uh key TTL um we Al we are also

going to be introducing some uh least

recently used uh semantics here um in

terms of how we do like cash eviction

and expiry and stuff like that so you

can have um some stronger cash based

semantics um with kind of like this lru

uh stuff um and again when we do release

this I will be doing more of a deep dive

into all of this um Batch get is

actually something that exists on

streams and KVs but where gets really

cool for KVs is if you have something

that um you know this the particular

structure of the thing that you're

storing is either like column based or

field based where you might have

something representing a user and the

user has an email and a password and an

ID and you can store all of those in

individual um entries like user. ID

user. name user. email and you can

actually use a batch get to get all of

those fields in one request um and then

easily map them to you know a structure

inside of your programming language of

choice um which is very very awesome and

just gets us a lot closer to some of the

semantics you'd expect from redus or

Dynamo DB or things like that and then

lastly one of the one of the things

that's missing that folks who are using

KV that would love to have this is uh

when ttls expire currently we don't get

any sort of watch notification for it

but we will be getting watch

notifications for any sort of system

delete events ttls evictions stuff like

that and so um that's something to

really look forward to in the next

version of nat server Nats 211 and I

will keep everybody up to date in terms

of uh when these features go live and

when we can start playing with them so

look forward to that okay so I think we

can now move on to diving into some

examples so I'm going to be using Cadia

Cloud to drive a lot of this but you can

do this via the CLI um the reason I'm

using Cadia Cloud here is cuz I wanted

to show some real like Regional um you

know movement of KVs mirroring stuff

like that so if I go over here to

streams um I have a KV called my KV

bucket and actually I was using this in

in my previous example um right now it

exists in Azure Europe West okay and so

I'm going to run a quick example um code

that's essentially going to just be like

doing a get every second second um from

this particular key value store and we

can kind of measure the latency here and

what we'll do is we'll measure the

latency and then we'll move this around

and see if we can get our latency kind

of uh lowered a little bit I'm going to

run uh G run main.go

and we're getting a value noise and it's

taking about 200 milliseconds now I'm in

uh Southern California in the US and

this KV store obviously exists in Europe

um somewhere in some Azure Data Center

so we're um we're getting about 200

milliseconds of latency um and and

that's just not going to be good enough

for what I want and so there's a couple

options that we have available to us

here I can go into uh this KV bucket and

I could simply just um change the

cluster to something like uh uh let's go

to AWS Us West 2 that's going to be

pretty close to me so when I hit save

what this is going to do is it's

actually going to move the bucket

mid-flight everything's going to stay

the same um you know clients that are

trying to access the bucket they'll

still be able to access the bucket uh

it's just going to mirror that and move

it over um automatically for us and you

can see that I've automatically now

dropped latency which is great um now

maybe this is what I want to do maybe

I'm doing a lot of Rights in Southern

California and I want my reads and my

rights to be fast and this is good

enough for me but what if I actually do

want the rights to be fast in Europe and

I want just the reads to be fast in uh

Southern California for me well what we

can do is I'm going to move I'm going to

go ahead and move this back to um to

Europe let's go Azure Europe West I'm

going to hit

save and then we should notice pretty

soon here yeah we're getting back up to

those 200 milliseconds in terms of

timing um so the thing that we could do

is if we wanted to make reads really

really fast uh for that particular

stream we can create a mirror for it so

I'm going to go to S Cloud I'm going to

create a mirror and I'm just going to

call this um you know my bucket mirror

you can call it whatever you want um and

I'm going to pick the kvi bucket and

then I'm going to set its cluster to uh

AWS Us West 2 and here's the cool thing

I everything is still happening the the

key Value Store still exists in Europe

I'm just creating a mirror inside of uh

AWS Us West let's see what happens we

drop our reads to back to those 40

milliseconds and that's because we just

created a mirror all the rights are

still going through Europe um but all of

our reads uh are you know all of the

keys are replicated and then being read

directly from um a mirror inside of

Southern California here uh which is

awesome very very cool so uh so that's

how we do some mirroring and replication

and moving of KV stores you could see

it's really really easy the second thing

that I wanted to talk about um is I want

to talk about leadership election so

we're going to write a a simple kind of

uh go program that kind of uses all of

the these optimistic concurrency control

Primitives to be able to um create a

little leadership election system and

what I mean by leadership election is we

want to have multiple programs running

but we only want one to be the leader

and to do this in a distributed system

requires a bit of well it requires some

something centralized to be able to kind

of be that uh system of record for who

can be the leader and we need a way for

these applications to try to claim

leadership um whenever they want and so

uh we're going to write a little

leadership election system um this is

very similar to like a distributed lock

if you've used one of those before um

but let's go ahead and do that so I

already have a little bit of code

written just to kind of remove some

boiler plate um and so we have kind of a

is leader and a name and a revision flag

available to us and then um we're

already starting to create this key

value store so we're saying js. Creator

update key value and uh we're naming our

bucket leadership we're setting our TTL

to about 3 seconds and the reason we're

using ttls here is if a leader goes

offline and never comes back online we

want to be able to expire that key so

that new leaders can come online so if

there's a disruption to service or

anything like that um their leadership

is forfeited I'm also setting Max bytes

here just because we're using Cadia

cloud and we absolutely need to have um

Max B set um for that and I'm just going

to uh check if there is an error in

creating this key value store and then

we could start uh writing kind of our

leadership code um okay so we have a

leadership key value key value bucket um

what I'm going to do I'm going to write

this in probably the most basic

barebones way possible because I know

not everybody's going to be using go for

this and we don't want to get into crazy

like you know go concurrency so we're

just going to do we're just going to do

the basic Brute Force way of this so I'm

going to put a for Loop here and I'm

going to uh sleep for one second um I'm

also going to just log real quick um

starting leader election sure um

actually let's say uh trying to become

leader perfect um so these clients are

going to try to become leader um before

they do so they're just going to sleep

for one second um and they're going to

check first if they are the leader then

they just want to refresh their uh they

want to renew their leadership so what

they're going to do to refresh the lock

is they're going to use the KV update um

now this is really important so they're

going to be using KV update because they

want to be able to essentially take a

particular key in that key value store

and refresh it um you know making sure

that it doesn't expire and so uh we're

going to say KV update we'll put in our

Nat's context um we'll use the key

leader for all of our locks and then we

could put in um we could put in their

name there that we give

them and we're going to be using

revision now this is really important

because if there's any like intermittent

connectivity and somebody else claims

ownership um we still have this is

leader variable that's going to be

outdated and Incorrect and so we want

the key value store to be able to tell

us hey you're working on outdated

information and you are no longer the

leader sorry dude um so this is why

we're going to be using the update

command here um we're going to say if

error is not equal to nil then we want

to say that they lost leadership so I'm

going to say uh

leadership

lost and we're going to set is leader to

false okay so that's what we do if

there's a leader um by the way uh we can

do a quick continue

here um we're actually going to do it

right

here because we don't need to execute

any more logic um for that one uh we

want to make sure that we're setting a

revision properly and then we want to do

an else so if if this isn't a leader

which is going to be most of these nodes

we want these to try and become a leader

and it looks like co-pilot is getting

pretty close here um in terms of the the

code that I wanted to write but but uh

let's just do this ourselves so we're

going to set our revision and error and

we're going to uh execute the KV create

command against leader and we're going

to want to set our name um and then uh

if there is a particular error here then

we want to handle it we want to say um

we want to just continue actually

because we didn't we weren't able to

become leader so we'll just try again in

another one second or so and um and then

if if there was an error um this could

either be an else or we have a continue

that stopping this so we could literally

just say that uh this thing became the

leader and uh we can set is leader to

true and that's really all that we have

to do for this particular leader

election system again simple Bare Bones

um very kind of brute force in its

approach but um it does the job so let's

actually try and uh fire this up I'm

going to go ahead and uh go to our

example we'll go to leadership and I'm

going to say go run um our leadership

example and I need to pass in an

argument for the node so I'm going to

say uh node

one and this is trying to become a

leader and it became a leader because

it's the only node it's the only node

that um exists right now so it was able

to claim leadership um but let's

actually fire up a couple more so we're

going to say node two and we're going to

say node three and look it looks like

these guys are trying to become leaders

um but they're going to be trying every

second to do to do so um if I go ahead

and kill node one somebody else is going

to pick up the leadership because that

uh key is eventually going to expire you

can see that uh node 3 is now the leader

now if I do a Nats uh KV get

leadership um I think that's KV store

and then who is the leader you could see

that node 3 is returned because that's

what we set inside of the the KV store

and so this is kind of a very

lightweight way that you can kind of do

leadership election with KV stores a

combination of update and create using

those revisions um you can have uh just

a really kind of easy way for people to

assume leadership and you could

obviously adjust any of these timings on

some of these things um but uh and you

could also kind of use watches and

notifications to speed some of this

stuff up now we are leaning on ttls a

little bit so until we get that um new

feature around TTL notifications we

won't be able to speed this up a ton but

um as you could see we have a lot of

really neat tools at our disposal to be

able to do things like distributed locks

or leadership elections um and that's

just scratching the surface of some of

the cool things that you could do inside

of Jetstream KVs so that's all I have

for today hopefully this was a a really

fun episode to learn more about jet

stream KVs we have so many more cool

pieces of content that are coming down

the pipe so please stay tuned and if you

didn't already please like And subscribe

um we have more events coming we have

Live Events we have amas we have long

form videos like this so uh stay

subscribed to the channel and I'll see

yall next time thanks so

[Music]

[Applause]

[Music]

much