Microservices and Publishing State versus State Changes

Question

Let's say I want a system where a service B's state should be updated according to changes in the state of service A. When A's state changes it can either publish

• its entire state
• only its changes in state

So let's say for example that A's state at points in time looks like

 t0  | [ ]
------------------
 t1  | [X,  Y]
------------------
 t2  | [X', Y]
------------------
 t3  | [X', Y, Z]
------------------
 t4  | [X',    Z]

It could publish each of those snapshots of its current state (right column) or it could publish only the changes like

-----------------------
 delta(t0, t1)| +X, +Y
-----------------------
 delta(t1, t2)| X->X'
-----------------------
 delta(t2, t3)| +Z
-----------------------
 delta(t3, t4)| -Y

which in theory could create an optimization. But a few things I see that would have to be guaranteed are

• Published events are consumed in correct order
• Published events that were "missed" by a service need to be recognized and somehow compensated for
• There is no bug in the delta algorithm

whereas if the entire state is published then

• If 2 published events are consumed in the wrong order then publishing a 3rd event corrects everything
• If a published event fails to be consumed then publishing a 3rd corrects everything
• No delta algorithm, so less complexity and compute resource on the publishing service

A few solutions I can think of to make the delta approach a little more robust add a lot of complexity:

• Publish both the changes and the entire state and a pointer to the previous event. The services consuming the event can figure out whether to process the delta or the whole data set.
• "Cycle" between publishing deltas and entire state. Maybe publish changes 9/10 times and then the entire state the other 1/10 of the time just to help correct things.

Both of those feel weird. I am interested in whether there exists a robust solution for notifying of "additions, removals and modifications" while ensuring eventual consistency in the system.

Answer 1

A third option is for the published events to contain no state information, and the event consumer is responsible to pull the state from the producer. The event may contain a callback to the producer and/or an ID for the data that has changed.

Of course the least complex and least efficient solution is for the consumer to blindly pull data from the producer on a schedule.

Answer 2

This is a really good question. The semantics of publishing deltas is essentially what is coined the event driven architecture if you want to do further reading.

The main advantage that events (deltas, in your definition) give you is transparency. Events are small and confined as they define something that happened to your system and are traceable. If there is another behavior you need to capture, you can add an event type. While with state changes, it lacks the transparency as to what happened; you'll probably have to dig back to all the different states and figure what had happened and if they're out of order, it may be difficult to reason about.

Also to the following points,

Tracking Deltas

There is no bug in the delta algorithm

I don't think its hard to assume. The implementation would be rather easy because you'll be checking the event type and operating on it so the processing in the branch should be rather small to handle.

Tracking States

If a published event fails to be consumed then publishing a 3rd corrects everything

What if the service is responsible for the state change has a bug and updates the record to an invalid state? Publishing the same 3rd state would reflect a consistent bug in downstream systems that depend on the state change. Using the events here decouples these two semantics, essentially state and what happened.