Layered System Constraint
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
The layered-system constraint means a component knows only the layer it is directly talking to. A client calls one public API and does not need to know whether that next component is the origin service, a cache, a proxy, or a gateway. The internal path can change while the public contract remains stable.
For example, a mobile app sends GET /orders/42 to api.example.com. A cache may return a reusable response. Otherwise, a gateway routes the request through a load balancer to the Order Service. The mobile app still sees one request and one response; it never needs the private address of the service instance.
This separation lets intermediaries add caching, security policy, routing, and load distribution. Because REST messages are self-descriptive, an intermediary can understand the method, headers, status, and media type it needs for its job. It must still preserve the public meaning of the exchange unless the contract allows a transformation.
The trade-off is extra work on the request path. Every layer can add delay, consume resources, fail, or make a problem harder to trace. Shared caches may recover some performance, but a team should add a layer for a clear reason and carry trace context across the path. This is a network-architecture constraint, not the controller-service-repository structure inside one Spring application.
Layered System Constraint
Direct Answer
In REST, a layered system means the client only talks to the next layer and does not need to know what is behind it. A request may pass through a cache, API gateway, or load balancer before it reaches the service. This keeps the client simple and lets the backend change or scale, although extra layers can add delay and make debugging harder.
Deep Dive & Architecture
Think of the public API as the front door. The client knows api.example.com, but it does not need the address of each internal service. That is the visibility rule: every component works with its immediate neighbour rather than depending on the complete topology.
Follow one order lookup. The cache first checks whether it may reuse a saved response. On a miss, the gateway applies shared policy and chooses the Order Service route. The load balancer selects a healthy instance, and that service reads the order. A response travels back through the same public boundary. The client does not need different code when another instance is added or the gateway implementation changes.
The layers work because the exchange keeps a clear meaning. A cache uses HTTP caching rules; a gateway understands the request method and selected headers; the client interprets the final status and representation. An intermediary may transform a message when its role and the contract allow it, but it must not silently turn one operation into another.
Fielding's trade-off is important: layering limits how much of the system each component must know and enables intermediaries, but it adds processing overhead and latency. Shared caching can offset some of that cost. In a real service, a trace ID and timing for each hop make the added path visible when a request fails or slows down.
Check your understanding
Answer these without looking back at the article.
- How is REST's Layered System constraint different from controller-service-repository layers?
- What jobs can an API gateway handle?
- What problems can too many network layers create?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.