Some of the things below might be a bit of a repetion based on what you know but let's see if parts of it can be useful for you still.
The idea of microservices is to design each service around a single responsibility or quite common a single domain. This would mean that you will have different services handling Product APIs, Order APIs, Basket APIs and Customer APIs. As you already guessed, this would mean you will have all this data split between different databases and services collaborate with eachother, never access their own databases directly.
This allows you to have all the business logic contained in one place and achieve that services are:
- Released and Deployed independently
- Replaceable and easier upgradable
- Scaled independently
- Easier & faster releases
- Easier to test
Implications
More things can go down
Implications of such approach is naturally a more complex deployment infrastructure and more things that can go wrong as services are communicating with each other typically over HTTP with REST APIs, but sometimes over pub-sub, Protocol Buffs or Thrift, or other light-weight messaging protocol. This leads to possible timeouts in communication, latency, etc.
You will have to account for "things can go down" scenario much more than in a monolith and handle it according to your requirements. There are libraries and tools that help you with, for example Spring-Cloud-Netflix project wraps in Netflix Hystrix for circuit breaker support which helps you handle timeouts with remote service communications.
Resource usage
When it comes to resource usage it depends on how you look at it. Multiple services combined will most likely use more resources than monolith, especially if you account for multiple database instances, etc. However let me give you an example when for instance deploying to AWS and using Auto-scaling support that AWS provides.
In a monolith you will scale the whole application. when the load on your application increases. This means that you will spin up more EC2 machines even if it's only a certain piece of the code that is being under pressure.
In a microservice architecture you are able to scale each service on it's own depending on usage. This can lead to a much better resource utilization and being more cost-effective at the end as each service will use only a fraction of what a monolith does.
A few words about UI
I think the UI should be treated as a separate service as well. It should only provide the UI itself but not the business logic for certain operations - it's a responsibility of each microservice. So if you have a webshop, you may end up with the following services:
- Frontend UI
- Purchase service
- Basket service
- User service
- Product service
- Order service
- Shipping service
- ... possible quite a few more.
The only logic your UI should have is how to display different type of data and then communicate with underlying services. However, UI can be combined by many different services too! As an example, Amazon has many different cervices that power each page you see and parts or the UI can be generated and shown by different UI services. It all depends on how small you want to make your services.
There is a very good book "Build Microservices" by Sam Newman that I strongly would recommend you read - it covers a lot of these things and much much more. It should also answer a lot of different questions that may arise over time the more you dig into the beautiful world of microservices.
