Handling rolling upgrades in app?

EventStoreDB
1

Hey,

How are you typically dealing with rolling upgrades of event sourced
apps? Specifically, if you have 3 servers, upgrade the first from v1
to v2, which now starts creating v2 events, and then the other servers
with v1 receives these events, what do you do? Close the subscription
and wait to be upgraded? Maintain two stream positions (one which you
will reread upon restart, and one with where you have successfully
read AND understood)? Any other tricks?

cheers, Rickard

2

This has nothing to do with event store (its just event sourcing in general)

Use weak serialization (say json) add a rule that you can't rename things.

3

This has nothing to do with event store (its just event sourcing in general)

I'm trying to figure out how to use a clustered event store. It's not
related to event store, per se, but usage thereof. Better suggestions
for forum?

Use weak serialization (say json) add a rule that you can't rename things.

How does that make any difference? V1 server will get an event, see
that it can't understand it, and then...? Once upgraded to v2, how
does it go back in time to reapply these? Or as the other suggestion,
once v1 sees an even it doesn't understand, simply stop (which causes
other problems).

/Rickard

4

"> Use weak serialization (say json) add a rule that you can't rename things.

How does that make any difference? V1 server will get an event, see
that it can't understand it, and then...? Once upgraded to v2, how
does it go back in time to reapply these? Or as the other suggestion,
once v1 sees an even it doesn't understand, simply stop (which causes
other problems).
"

metadata to describe this behaviour (e.g. must understand). normally
your code when then reject the client with a retry after (assuming you
have a load balancer in front of you). There are other ways to handle
e.g. forwarding internally as well.

5

Upgrade the servers [assert backwards compatible] before the messages/clients.

6

Upgrade the servers [assert backwards compatible]
before the messages/clients.

I only have “the application”, which creates events and reads events
to update the read model. So it sounds like I have to have feature
flags for every new feature, deploy the apps with code first, then
do another rolling upgrade with config to turn features (=new
events) on.

/Rickard