Ideally you don't have to sync the data because one service owns that data. Other services request that data via api. In a RESTful world those api requests are cacheable.
Is the best practice to not use entity services?
For updates and maybe reads, it's a different story.
\d Person
[A bunch of table schema stuff]
Referenced by:
TABLE "Billing" CONSTRAINT "billing_id_fk" FOREIGN KEY (id) REFERENCES Person(id) ON DELETE CASCADE
(I typed that off the type of my head so it might not be quite correct.)
So the basic premise is that there is no shared database, and thus having the database enforce cascading deletes is not an option.
The Billing service can then reference People or Businesses (and if Businesses, then sub-People), bill to an Address, etc.
No one's saying every object should be a service; you need to find the correct lines to divide across.
In our system (which has been service-oriented for five years), we don't do deletes. We do 'inactive' (UPDATE table SET ACTIVE=0…), but never deletes.
Especially in a case of your billing example, you never want to delete a person or address, because that's historical data you need to retain, but we just keep everything. If it goes in the database, it's because we want to keep it forever.
You'd have to allow for propagation delay. Plus the possibility of a message storm if you delete something fairly fundamental.
You're still screwed if you complete a transaction on the deleted person's still-existing account, now that your system is no longer transactional...
It adds complexity of course but that is the give/take when you use microservices.
I think you basically have to learn to live in an eventually consistent world. In the case of people being deleted I would imagine that the user service exposes a pub/sub interface where address and billing services subscribe to "delete" events.
http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pd...
The problem of services being up/down has been solved with service discovery e.g. Consul, Etcd, Zookeeper.
If System A needs to tell System B about an event in order for A and B to remain consistent, but B is down, you've got eventual consistency, because B can't become consistent with A until it's back up and has performed whatever recovery is necessary to process that event. Service discovery does nothing to solve that problem.
In addition, the network isn't just up or down. It's varying shades (dare I say, 50 shades?) of down or broken. A single machine might not be accessible due to a switch issue. An entire rack or aisle might be compromised by a bad router or faulty routing table. A network cable might be flaky. The truth is you just don't know, and that's all inside a single LAN.
Your service discovery system could be able to see service {A,B,C}, but service A can't talk to B or C due to network issues. It happens.
It explains how to manage situations like this.
One may argue that in this case, "people" service doesn't go by description of micro-service as given in the article. But we need to understand that services get called in some context and there has to be someone there to do the plumbing. That someone can either be a db query, some code in the service, or app/application calling the services. And "generally" you would prefer service code over other two and hence a composite service.
IMO it may also be okay to have People, address, billing under one schema if service granularity and context allows so.