Hi Carl Byrd,
Thanks for your question.
I think the way microservices have evolved over the years, the intent is to make every service more or less independent so that even when there's any kind of issue in one microservice it doesn't affect the other parts of the overall application. Having said that, there's no one answer to your question around database architecture, as it also depends on which DB service is being used, what's the interdependency between services, is data being stored in a single/multiple regions or if there are any specific data localization regulations which need to be adhered for the microservices, In general, the most common
pattern which I have started to see is that microservices typically tend to use simple data storage and access patterns for which NoSQL offerings like AWS DynamoDB are best. So if thats the case, then each of the microservice can have its independent table and that keeps proper isolation across the board. On the other hand, if there's a need to have a relational database, like SQL server, then most of the times, I see customers use same database but with different tables/schemas to again create logical boundaries between microservices. So net-net, there's no one single pattern which fits the bill and it depends on various reasons like I mentioned earlier.
Hope this helps and look forward to you having your feedback on the book :-)
Thanks,
Kamal Arora