As described in Chapter 1, Building Big with Go, the components are organized into tiers and communication is restricted only between adjacent layers. The layers are distributed across machines:

This architectural style can be thought of as an inverted pyramid of reuse, where each layer aggregates the responsibilities and abstractions of the layer directly beneath it. When the layers are on different machines, they are called tiers. The most common example of strict layering is where components in one layer can interact only with components in the same layer or with components from the layer directly below it.

The layers of an application may reside on the same physical computer (networking stack), but in distributed systems, of course, these are on different machines. In this case, they are called an n-tier architecture. For example, a typical web application design consists of the following:

• A Presentation layer: A UI-related functionality.
• HTTP server layer: This is a network server responsible for handling HTTP/HTTPS and features such as reverse caching, persistent connection handling, transparent SSL/TLS encryption, and load balancing.
• A Business Logic layer: Hosts the actual processing to be done as per the business rules. This is typically handled by code deployed in web containers or frameworks. In Golang, the containers tend to be much less complicated compared to other languages, such as Java (JAX-RX or Spring MVC).
• A Data Layer: Deals with interactions with durable data (database). This is generally built using mostly reusable code, configured with application specifics. In initial versions, this layer is co-located with the Business Logic layer.

In which tier to place which layer is an important design decision that the architect has to grapple with. There is an entire spectrum in terms of responsibility allocation:

We should start by having clients as dumb as possible (left side of the preceding diagram), since this allows maximum flexibility in terms of reuse (across clients) and extensibility (generally, server code is easier to change and deploy compared with client code). However, some more layers may creep into the client to solve for things such as latency optimization.