Is Event sourcing a good fit for database sync (master-multiple-slaves)?

Question

I'm looking for a good way to maintain in sync local sqlite databases that could be offline to a master one, for a invoice app.

Then I read about EventSourcing and Log structured storage and wonder if it could be a better way to maintain in sync the data. However, I never before use event sourcing.

Exist a master database with all the invoice info (customers, invoices, payments, etc), and each local database in a mobile device have a full copy of it, and must stay as current as possible. Most of the time it will be on-line, but mobile internet is unreliable and could be offline for a while.

Most likely, edit on the same record is not common, even for invoice where each salesman commonly have his own subset of invoices.

Is good idea to use Event Sourcing here, or similar? Any pointers in how do this well?

The use of local sqlite is the only hard requirement, I'm totally free in the backend.

Answer 1

No, because given the detail on the question you are jumping the gun.

If you are going to find the optimal solution, you need to reason about the "conceptual" needs first, before reaching for a particular "implementation" tool.

---

You need to consider:

• Will each replica have a full read-only copy of the source? Event-Sourcing is probably ideal
• Will each replicate have a full read-write copy of the source? This gets complicated. You might be able to use Event-Sourcing, if you can separate the local INSERT/UPDATES, and track changes to replicate later back to the server. But even then, there are many complexities to consider.
• Will each replica have a partial read-only copy of the source? You might conceptualise with Event-Sourcing, but implement with a global Event-Sourcing table, and a VIEW to filter to a subset.

There is probably more, but this section is here to illustrate the fact that you might be jumping the gun.