Think of the microservice architecture as an analogy of many orbital satellites, each fulfilling its own duty for planet Earth. Some space stations evaluate cosmic radiation, others study the solar system, third stations conduct biological experiments, and so on. The number of each type of space station can easily be scaled according to demand. For example, to obtain better telecommunication coverage, the Iridium operator could launch an additional number of satellites into the orbit.
Within the ecommerce microservice architecture, there are many microservices and a core module. The core could be a very small and lightweight for better system flexibility. Microservices communicate with each other and core via an API. Among microservices running bounded service functionality, there are microservices for system duty — for example, to discover an appropriate microservice in the system through a request from a functional microservice.
When building microservice architecture, the DevOps team would be responsible for the product throughout its entire lifecycle, including development, maintenance, and decommissioning. This forms a “product mindset” and means strong ties between a technical product and its business capabilities. A direct relationship is created: how the application helps its users to expand their customer experience.
When talking about headless ecommerce, front ends (aka heads) are fully decoupled from the back end (aka body) and they communicate only through API. For headless, it doesn't matter if the system is a monolith or a microservice one. The difference lies in the effectiveness, because with a microservice architecture, headless brings better flexibility to implement business logics compared to headless working with monolith (by API).
From the space allegories point of view, the front ends could be far-space satellites and the Earth is the back end. If these far-space satellites communicate directly to the Houston control center, this will be a “headless + monolith” architecture. If far-space satellites only communicate to space stations in near-earth orbit and these stations receive and transmit data strictly according to their bounded functional service, this will be a “headless + microservices” architecture.
Summarized: Microservices enforce the bounds of services, keeping the code healthy, clear, isolated, and encapsulated in separate connected modules. If a module (i.e. microservice) becomes buggy, then this non-optimal program code only remains there and does not spread to other parts of the IT system. This brings more flexibility in the development and implementation of the front ends; the headless approach could be combined with microservices.
However, the microservices approach is more innovative than a monolith, but not the best ever. The understanding of how to translate a task from business decision makers into an IT solution deepens as developers go further. Therefore, the microservice code has to be constantly rewritten (refactored which leads to the descaling of microservices more and more to a smaller functionality, and the system becomes too granular. This could affect reliability and requires more testing time, more involvement of technical support for quick bug fixing.