I haven't found a description of the service architecture I frequently see; but, the Internet is lousy with descriptions of three tier and event driven architectures.
This write-up is for Future Me to point at when asked how to design a network service.
tl;dr
- A server cluster, scaled horizontally
- A queue cluster, scaled vertically or sharded
- A worker cluster, scaled horizontally
- A database cluster, scaled vertically or sharded
The "three tier architecture" is the reference pattern for web services:
- Presentation Tier (Client)
- Logic Tier (Server)
- Data Tier (Database)
Meanwhile, the "event driven architecture" is the reference pattern for streaming data services:
- Messaging Tier (Queue)
- Logic Tier (Worker)
- Data Tier (Database)
N.b. sometimes there's no data tier, and the presentation tier (local-first) or messaging tier (unbundled database) do double duty as a data tier.
But, the key differences between the two architectures are:
- A client requests a response from a server (push)
- A worker polls for an item from a queue (pull)
Any website beyond trivial will naturally grow to require a job system, even sending email is touchy enough that it is often spun off as a task.
Imagine the platonic ideal of a web service. It can only respond to requests from clients.
Imagine the platonic ideal of a streaming data service. It can only poll for items from a queue.
The web service enqueues any asynchronous work it needs done and delegates it to the streaming data service.
Our imaginary model architecture looks like this:
I have never seen this model architecture in a single service. Not in reality.
But, if the server and worker share the same database? Yes. Yes.
I have seen that so many times that I called it the unnamed architecture.
I asked my friends, peers, and favourite part of the Internet what the above architecture is called. I didn't think it was three tier, nor had I yet considered that it was the human centipede of software design. But, I was surprised when some people said it was still a three tier architecture.
These are a few reasons I got:
- All non-trivial systems have asynchronous work; it's implicit in the three tier architecture
- Responding to requests from a client and polling for items from a queue are both "logic"
- A queue is a database; moreover using a database as a queue is a great example of boring technology!
And if tiers are abstract concepts like the trinity of UI, logic, and data, then I agree with the above points. It's all three tier!
My understanding of what makes a "tier" a tier is that a tier can be developed and operated independently.
Thus, I question how tier-y the logic and data tiers are:
- Their responsibilities are different; requests vs. items, complex data queries vs. a queue (functional separation)
- Their resources are independently managed; storage, compute, and network (physical separation)
- Their communication models are not the same; synchronous vs. asynchronous (logical separation)
- Their staffing needs are unique; frontend vs. backend (organisational separation)
My gut tells me that the tiers may not be conceptually useful when the architectures are superposed.
But, let's put a pin in that, for now.
Why limit ourselves to a web service that can only service requests from clients? We could have an overly complex hybrid service that can also stream events!
For example, imagine some other service is publishing the account IDs of cancelled customers. Our service should probably cancel those accounts in our database!
Seriously, though, Big Tech is services that both respond to requests and process events.
I hear that "gRPC" and "Kafka" are fighting words in San Francisco.
Remember that pin?
Are tiers still useful? I've never, ever, discussed a "logic tier." But I've cost and saved companies millions of dollars by planning capacity for server and worker pools, sharding databases, and trimming queues.
Going back to the drawing board, here is the service architecture that I frequently see, eliding gory details like caches and load balancers:
- A server cluster, scaled horizontally
- A queue cluster, scaled vertically or sharded
- A worker cluster, scaled horizontally
- A database cluster, scaled vertically or sharded
I couldn't find this diagram anywhere else on the Internet. You're welcome, Future Me.
