Designing scalable microservices
Service boundaries are a cost. Scale the ones the domain actually needs; keep the rest as a modular monolith until the seam is real.
Personal experience
Technical leadership on an ecommerce platform (Armirene) and R&D leadership on a private ERP (Soga) both require the same judgment: where a boundary is worth the operational cost, and where it is not.
Technical perspective
A microservice is not a deployable unit that happens to be small. It is a unit of data ownership, failure, and release. If two services cannot change independently — because they share a database, a lock, or a release train — they are not services. They are a distributed monolith with extra latency.
The first scaling question is not Kubernetes. It is: what is the unit of contention? If the bottleneck is a table, splitting the process that writes it does not help. If the bottleneck is a team’s release cadence, a service boundary can help. If the bottleneck is a third-party API, neither will.
Contracts should be versioned, boring, and explicit. Synchronous fan-out between many services is how latency budgets disappear. Prefer a coarse API at the edge, and keep chatter behind it.
Architecture
Coarse edge, independent services
Client
API Gateway
Service A
Service B
Service C
Owned data stores
Technical perspective. A gateway should hide internal chatter, not multiply it.