08 — The Application Layer: Splitting the Web Tier and Finding Services

"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]:

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

[2] M. Fowler, "Microservices," martinfowler.com, 2014. [Online]. Available: https://martinfowler.com/articles/microservices.html

[3] Amazon Web Services, "Introduction to microservices," AWS. [Online]. Available: 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

[5] "Microservices," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Microservices