Client-Server Architecture
Client-server is the default architectural shape this entire course has assumed without saying so: a client initiates a request, a server holds resources and processing power the client doesn't, and responds. Every HTTP request, every API call, every database query is an instance of this same asymmetric relationship — one side asks, the other side is authoritative and answers. It's worth pausing on it explicitly as an architectural choice, because Peer-to-Peer Architecture exists specifically as its counterpoint.
Microservices Architecture
A microservices architecture splits a system into many small, independently deployable services, each owning a specific piece of functionality and, typically, its own data. It's the opposite structural choice from a monolith — one large application, one codebase, one deployment unit — and the entire Distributed Systems and Microservices module was, in effect, building up the vocabulary this lesson needed to describe precisely.
Serverless Architecture
Serverless takes Microservices Architecture's "independent, small units of deployment" idea and pushes it one step further: instead of deploying a service that runs continuously on infrastructure you provision and manage, you deploy a single function, and the cloud provider runs it only when triggered, for exactly as long as it takes to execute, then stops it entirely. There are still servers underneath — the name refers to not having to think about them, not their literal absence.
Event-Driven Architecture
Event-driven architecture is a system-wide design choice: services communicate primarily by producing and reacting to events — facts about something that already happened ("order placed," "payment failed," "user signed up") — rather than by calling each other directly and waiting for a response. This module's Asynchronous Communication lessons (Pub/Sub, Message Queues, Change Data Capture) covered the specific mechanisms; this lesson is about the architectural decision to build a whole system around them as the default way services talk to each other.
Peer-to-Peer Architecture
Peer-to-peer (P2P) architecture removes the central authority Client-Server Architecture is built around entirely: there's no server, only peers — nodes that are simultaneously clients and servers to each other, requesting resources from some peers while providing resources to others, with no single node that everyone else depends on.