I am interested what would be the ideal way to scale Microservices in DDD world?In case of the following scenario, where Sales context is hosted as a microservice on a different host then Support context, if sales context exceeds hardware limitations, would you:a) scale vertically (increase the resources of the server) b) scale horizontally (adding more servers) c) split microservice so for example Sales Context is now (just a generic solution)Sales Teritory Context (Customer,      Product, Teritory, Sales Person) and Sales Teritory Oportunities     Context (Teritory, Opportunity, Pipeline)As an alternative, would it be a good approach to use all three techniques but in a specific order ie. so first split microservice (software scale), then scale horizontally (easier hardware scale in terms of maintain application), and then scale vertically (more difficult hardware scale).I know each scenario is specific, but I would like to know what technique do microservices and DDD encourage?
How to scale microservices in DDD world?
domain driven design;domain model;scalability;microservices
THere is no best solution for this question.  It's only a question of costs and benefits:  Vertical scaling is often the easiest path, until a certain stage:  extending processing capactity of the services with additonal cores, RAM, network cards, faster disks is mostly a plug & play effort; Moore's law combined with decreasing hardware prices are on your side.  However, when you come close to the limit of your hardware architecture, and if you can't split your microservice further, moving to the next high volume server technology might require much more investment, and one day you'll be close to the financial or technical limits.  Horizontal scaling is the most flexible.  Containters in large server farms are nowadays a comodity.  With this approach you generally can reach much higher volumes than with vertical scaling at a better cost (compared to buying a huge supercomputer).  However, this requires your the bottleneck microservices is designed to be run in multiple instances (e.g. stateless rest API instead of state dependent API; use of messaging queues, etc. ).    Partitionning of data between services based content criteria (e.g. geographic location of customer) is a very interesting approach. It's common business for microservices. But you need some dispatching mechanisms that the right service instance processes the right requests.  Combined with horizontal scalability, this could help to get rid of any bottlenecks, and optimize network performance, especially  if you manage to use a geographic partitionning reflevant for your users (e.g. put the data on the continent where most user access it).  However this is also the most delicate to design : it requires a very good knowledge of data dependencies accross the partitionning criteria and services, as well as somy dynamic registries to manage the deployment scheme.  So now, up to you to balance the pros and cons of each approach in your context. 