Andras Gerlits
1 min readMar 7, 2024

--

The problem of data federation is a superset of event-streaming or even remote method invocations. In the end, all these problems can be reduced to the problem of communicating some information between remote computers over a network safely. We solve this problem generally, by relying on the only ACID store the developer has access to and extending its reach from a "local-only" scope to a federated one via a message-bus. The promises remain the same, so this effectively means that now you can communicate events, pick them up and process them transactionally, all through your own database.

In case of a failure, the transaction will be rolled back and the global state won't be affected. You change your mind in the middle of a transaction, no messages are sent to others. Records will always have the right consistency guarantees, you could even start putting unique constraints on event-attributes, for example. You can even share some state safely between different services, like information about the currently running process, audit or just any shared data more than one service needs to know about. We do all this while conserving loose coupling advantages.

--

--

Andras Gerlits
Andras Gerlits

Written by Andras Gerlits

Writing about distributed consistency. Also founded a company called omniledger.io that helps others with distributed consistency.

Responses (2)