Two types of Service Discovery patterns: Client-side Discovery & Server-side Discovery. Both patterns work with a Service Registry.
For Client-Side, the client contacts the Service Registry and then picks (randomly, or via other algorithm) one of the available server resources. For Server-Side the client contacts one end point (a load balancer for example), and the end point directs traffic to available resources registered with the Service Registry.
The Service Registry needs an up to date list of healthy resources, which can be maintained by API endpoints for registration, deregistration, and health checks.
Pros for Client-Side: No other architectural items (besides the Service Registry)
Cons for Client-Side: Each client has to maintain the service discovery logic, and selection.
Pros for Server-Side: Only one end point for clients, discovery is abstracted away from clients
Cons for Server-Side: Load Balancer becomes one more element in your architecture.
Microservices should each have their own backend data store. Sharing the database would couple different Microservices together, data should only be accessed via the respective APIs. This also allows each Microservice to choose the best data store for their needs, whether it be a relational DB, NoSQL DB, or some other source.
Since you have data responsibilities it’s not plausible to have atomic transactions between services. Enter Event Driven Data management. When an event occurs in one service, it then publishes a message to a message broker, which the other Microservices can subscribe to. This can cause a chain of tasks to run, and workflows to be processed. These are not ACID transactions however.
Messages should be architected to ensure at least (or exactly) once processing. Making sure that the processors are idempotent helps with repeated messages.
The downside to EDD is that is is more complicated to develop with than ACID transactions. You have to worry about data consistency. Operations that query multiple services, or update data to multiple services.
The end of the article describes an interesting paradigm shift for achieving atomicity. Instead of storing an object with it’s state, you store the events to that object (creation, updating, etc) and then subscribe to those events from the other services.
Another couple good articles. It’s one thing to read about, and another to implement though. Seems like AWS helps a lot with Server-Side registry in their ELBs.
The Event Drive Data Management was a great read and a lot of thought provoking ideas. It had a nice little refresher on database ACID principles as well.