--- title: "08 — The Application Layer: Splitting the Web Tier and Finding Services" uid: application-layer tags: ["application-layer", "architecture", "service-discovery", "roadmap:system-design", "microservices", "system-design"] excerpt: "Separating the web layer from the application layer lets each scale and change independently — and once services are independent, they need a way to find each other." date: 2026-08-13T03:27:33+0000 source: https://www.aveshina.my.id/en/blog/application-layer --- "Just add more boxes" was my reading of the web-tier split, and it missed the why. Writing it down made the reason explicit: **separating the web layer (HTTP handling, routing) from the application layer (business logic, the "platform") lets each scale and change independently.** [1] Adding a new API means adding application servers without necessarily adding web servers. Once you split, the single responsibility principle pushes you toward smaller services — and those need a way to find each other. The framing that landed is that the application layer split is not about performance; it is about **independent lifecycle**. The web tier and the platform tier change at different rates, scale at different rates, and fail in different ways. Coupling them means a change to one forces a redeploy of the other. Separating them is the same reasoning that separates any two concerns: localize the blast radius of change. ## The split, and what it costs The mechanical picture is two (or more) tiers behind the load balancer [1]: ```figure ``` The honest cost is that this split is not free. A loosely-coupled multi-tier system demands a different approach — architectural, operational, and process — than a monolith [1]. Microservices add deployment and operational complexity. The single responsibility principle that justifies the split is also what multiplies the number of moving parts you have to deploy, monitor, and debug. ## Microservices: services as the unit of independence Closely related to the application-layer split are microservices — a suite of independently deployable, small, modular services, each running its own process and communicating through a well-defined, lightweight mechanism to serve a business goal [2]. The Pinterest example the roadmap uses is the clearest illustration: instead of one application, you have a user-profile service, a follower service, a feed service, a search service, a photo-upload service, and so on [2]. Each can be shipped, scaled, and owned by a small team independently. The trade-off is the same as the tier split, amplified. Small teams with small services can plan aggressively for growth [1]. But every cross-service call is now a network hop, every service boundary is a potential failure surface, and distributed debugging is genuinely harder than in-process debugging. Microservices are a tool for organizational and scaling problems, not a default architecture — a small team with a small system is usually better served by a well-factored monolith. ## Service discovery: how independent services find each other The moment you have more than one independently-deployable service, a new problem appears: services need to find each other, and their addresses change as instances come and go. **Service discovery** is the pattern that solves this — systems like Consul, etcd, and Zookeeper keep track of registered service names, addresses, and ports [3][4]. A service registers itself on startup; callers query the registry to find healthy instances rather than hard-coding addresses. Health checks are the other half of it. The registry periodically verifies each registered instance — often via an HTTP endpoint — and drops instances that fail [3]. That is how a caller avoids sending traffic to a service that has died but not yet been de-registered. Both Consul and etcd also include a built-in key-value store, which is useful for shared configuration and other small bits of coordination data [3]. The way of thinking I keep: in a monolith, function calls find their target at compile time. In a microservice system, the service-registry replaces that — it is the runtime lookup table that turns "call the feed service" into "call one of these three healthy instances." ## How I use this The decision check is about lifecycle and ownership. If two pieces of the system change at different rates, are owned by different teams, or need to scale independently, separating them into tiers (and then into services) pays for itself. If they change together and are owned by one team, the operational tax of a distributed architecture is not worth it — I keep them in one process. And when I do split, service discovery is the first piece of plumbing I reach for, because hard-coded addresses are the fastest way to make an independent service fragile. ## References [1] W. Le, "Intro to architecting systems for scale — the platform layer," lethain.com. [Online]. Available: [http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer](http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer) [2] M. Fowler, "Microservices," martinfowler.com, 2014. [Online]. Available: [https://martinfowler.com/articles/microservices.html](https://martinfowler.com/articles/microservices.html) [3] Amazon Web Services, "Introduction to microservices," AWS. [Online]. Available: [https://aws.amazon.com/microservices/](https://aws.amazon.com/microservices/) [4] D. Martin, "Service discovery," system-design-primer (open source), 2024. [Online]. Available: [https://github.com/donnemartin/system-design-primer#Service-Discovery](https://github.com/donnemartin/system-design-primer#Service-Discovery) [5] "Microservices," Wikipedia. [Online]. Available: [https://en.wikipedia.org/wiki/Microservices](https://en.wikipedia.org/wiki/Microservices) ```quiz Q: The primary reason to separate the web tier from the application tier is… - raw performance — separate tiers are always faster - independent lifecycle — each tier can scale and change at its own rate correct: 1 explain: The split is about independent lifecycle and blast-radius isolation, not raw speed. Each tier can be deployed and scaled without forcing a redeploy of the other. Q: A service registry (Consul, etcd) is used to… - cache database query results - let services find each other's healthy instances by name at runtime correct: 1 explain: Service discovery replaces hard-coded addresses with a runtime lookup: services register, callers query, and failed instances are dropped via health checks. Q: Microservices are best described as… - a default architecture every new project should adopt - independently deployable services each owning one responsibility, communicating over lightweight mechanisms correct: 1 explain: Microservices are independently deployable, modular services with one responsibility each. They solve organizational and scaling problems but add operational complexity — they are not a universal default. Q: Which trade-off does adopting microservices most directly introduce? - fewer moving parts to deploy - more deployment and operational complexity, plus network hops between services correct: 1 explain: Microservices multiply moving parts: every boundary is a network hop and a failure surface. The benefit is independent scaling and ownership; the cost is operational complexity. ```