Application Server

Basic System Design
≈ 2 min read

This is where application logic executes

After passing through the external layers, a request reaches an Application Server — an application instance that understands the domain operation: create an order, fetch a profile, calculate a price, or perform another action.

In System Design, it is useful to treat an application server as a running backend application instance, not as a specific Java product with that name. It is a process or node that accepts a request and executes business logic.

request
  -> routing
  -> validation
  -> business logic
  -> response

An instance should have a clear responsibility

An application server does not need to perform every infrastructure function itself. TLS, external routing, or global limits may live on earlier layers, while the application focuses on domain logic and communication with the dependencies it needs.

This separation makes scaling and maintenance easier: shared infrastructure policy changes independently, while application code remains focused on product behavior.

Stateless instances are easier to scale

If essential state for a particular user is not tied to the memory of one process, any suitable instance can handle the next request. The load balancer can then distribute traffic freely, and application servers can be added or removed as load changes.

This does not mean the system stores no state at all. The point is that an application instance should not be the only place where critical information needed by the next request exists.

Horizontal scaling requires more than starting additional processes. You need to make sure the instances are truly interchangeable on the request path and do not depend on unique local state.

The application has limits too

Every instance is limited by CPU, memory, worker or connection counts, and the speed of external dependencies. The number of application servers should therefore be chosen from measurements and expected load rather than by intuition.

If one instance can sustainably handle a known amount of traffic at the required latency, that becomes a basis for estimating instance count and the headroom you need.