Microservice architecture structures an application as loosely coupled services organized around business capabilities. Each service can be deployed and scaled independently and assigned to a team for code ownership. This is a form of feature-based, or Y-axis, scaling: instead of copying the whole application, you split it by function. section 2.3 section 2.2.3
Start with the business model, not a target number of services. A monolith is often the simpler starting point because it helps reveal business capabilities. Reassess decomposition when scaling problems, slower development, or longer release cycles make independent services valuable. Smaller releases and independent scaling are potential gains, not reasons to split every application. section 2.3 section 2.6
E-commerce service boundaries
An e-commerce application can separate product, cart, checkout, payment, and shipping capabilities. Checkout needs cart items, a shipping address, and a payment charge. With gRPC, it calls those services through generated client stubs added as Go dependencies. These boundaries support separate ownership, but a former in-process function call is now a network call that needs fault-tolerant handling. section 1.4.1 section 1.1
Figure 1.1 Architecture diagram of an e-commerce product built with Go microservices on top of Kubernetes, including CI/CD flow and observability
The architecture diagram places the e-commerce services in a Kubernetes environment alongside CI/CD and observability, showing the deployment context around the service boundaries. section 1.4
Service independence adds distributed-system work. Interservice communication must remain reliable, and data consistency needs deliberate handling; synchronous request/response and asynchronous messaging are available patterns. gRPC provides generated stubs and communication features, while saga patterns address consistency. Choose these mechanisms for the boundaries and failure modes you actually have. section 1.4.1 section 2.3 section 2.6
