Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Standalone conceptMechanismChapter III · Operations · Building block 10 of 17

Scaling

A measured capacity limit calls for a targeted change to the bottleneck resource.

By Michael Meierhoff · Meierhoff Systems

  1. ResourceResource: Capacity is added at a bottleneck.
  2. DirectionDirection: Vertical and horizontal changes differ.
  3. EffectEffect: End-to-end behavior confirms the gain.

Context

Why this is important

Adjust capacity through justified resource changes.

Adjust capacity through justified resource changes.

Shop example · Mapping

Scaling: inspect the decision

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. Before a campaign, operations adds shop web instances after a test identifies CPU as the bottleneck. Order modules remain within the same application and continue using the shared database. A second test shows that database write capacity saturates before web capacity. The team therefore scales the database path separately and measures latency, queue depth, and cost. The assumed load values remain explicit test assumptions.

This is how you read the picture

  1. Resource Resource
  2. Direction Direction
  3. Effect Effect
Scaling: inspect the decision
ConceptMeaningReview question
ResourceCapacity is added at a bottleneck.Which resource is examined separately after web capacity?
DirectionVertical and horizontal changes differ.Which data supports a scaling change?
EffectEnd-to-end behavior confirms the gain.Why might another web instance not fix the database bottleneck?
Zusätzliche Instanzen helfen nur, wenn Arbeit geteilt werden kann und gemeinsam genutzte Abhängigkeiten mithalten. Zustand, Startzeit, Koordination, Kosten und Rücknahme bestimmen, ob die Änderung den gewünschten Nutzen bringt. Use the questions in the second column to test this scenario.

Benefits & limitations

Helps if:

  • Adjust capacity through justified resource changes.
  • Measure the bottleneck, change targeted capacity, and test again.

Boundaries

  • More resources can create another bottleneck or higher costs.
  • Horizontal and vertical scaling change cost, failure domain, and bottlenecks in different ways.

In practice

  1. Measure CPU, database write capacity, queue length, and latency before adding instances; tie every change to an observed bottleneck.
  2. Increase only web capacity first and repeat the same load test; check whether the bottleneck shifts to the shared database and which modules are affected.
  3. Then test a targeted database change separately and compare throughput, latency, and operating cost while the seven modules remain in the modular monolith.
Read the detailed explanation

Scaling changes available capacity by using larger resources (vertical) or adding instances (horizontal). The decision concerns compute, storage, concurrency, and data and should target the actual bottleneck.

Additional instances help only when work can be distributed and shared dependencies can keep up. State, startup time, coordination, cost, and reversibility determine whether the change delivers its intended benefit.

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. Before a campaign, operations adds shop web instances after a test identifies CPU as the bottleneck. Order modules remain within the same application and continue using the shared database. A second test shows that database write capacity saturates before web capacity. The team therefore scales the database path separately and measures latency, queue depth, and cost. The assumed load values remain explicit test assumptions. backpressure and skalierbarkeit help compare this decision with adjacent concerns.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Which resource is examined separately after web capacity?

    View the solution with justification

    The database as a separately measured bottleneck.

  2. ApplyingTransferred to a new situation

    Which data supports a scaling change?

    View the solution with justification

    Bottleneck measurements and a cost and impact comparison after the change.

  3. EvaluateWeighing an alternative

    Why might another web instance not fix the database bottleneck?

    View the solution with justification

    More web capacity can increase database load without increasing its throughput.

Ten times more orders

Compare capacity, distribution and bottlenecks in the shared learning example.

Explore scaling in the shop

Explore further

Find variants and links to standalone concepts here.

Vertical scaling

Vertical scaling gives an instance more CPU, memory, or I/O capacity and adjusts a bottleneck within the same application. It is often operationally simple, but remains limited by instance ceilings and a single failure domain.

Horizontal scaling

Horizontal scaling starts additional instances of the same application and distributes requests across them. It requires stateless or externally stored sessions; shared database and write bottlenecks do not automatically scale with it.

Autoscaling

Autoscaling adjusts the number or size of instances using measured signals and defined policies. It suits predictable load variation, but operates within startup time, limits, warm-up periods, and the available resource budget.

Further building blocks

OperationsBackpressureContext and comparisonOpening OperationsLoad BalancingConceptual connectionOpening RequirementsScalabilityChanging capacity supports the quality goal.Opening

References

Continue on the learning path

Next in Runtime & operations: Load Shedding.

17 Building blocks

Continue withLoad Shedding