Scalability is the ability to accommodate more work by increasing an application’s capacity. In a microservices application, that does not have to mean enlarging everything at once: a heavily used service can receive dedicated resources or be replicated without scaling every other service. section 1.9
Choose a response to the part of the system under pressure:
- Scale the cluster vertically or horizontally when the wider application needs more capacity. section 12.3
- Scale an individual microservice horizontally when its workload is the bottleneck. section 12.3 section 1.9
- Consider elastic scaling for the cluster or individual services as another route to capacity. section 12.3
- Scale the database separately when data workload outgrows its current resources. section 12.3.6
Keep each microservice’s database separate, even if several databases initially run on one server. A database shared between different services creates a fixed integration point and potential performance bottleneck. If one separate database grows too large, move it to a dedicated server; for an extremely large MongoDB database, sharding can distribute it across multiple virtual machines. section 12.3.6
Figure 12.17 As our application grows larger, we can scale it by splitting out large databases into their own independent database servers.
The figure shows the incremental database path: start with separate databases, then move a large one onto its own server when its workload warrants it. section 12.3.6
Scale for an observed need, not a guessed future. Premature changes can complicate development and make later scaling harder. Cluster configuration changes also carry risk: try them on a separate instance rather than infrastructure that staff or customers depend on. section 12.3.7 section 12.1
