Vertical vs Horizontal Scaling
Scalability introduced the two ways to give a system more capacity: make one machine bigger, or add more machines. This lesson is the deeper, dedicated head-to-head that lesson promised — the first, and in many ways the template, for every other paired tradeoff in this module.
Concurrency vs Parallelism
These two words get used interchangeably in casual conversation, but they describe genuinely different things, and the distinction is a favorite precision-check in interviews: concurrency is about structuring a program to deal with multiple things at once; parallelism is about actually executing multiple things at the exact same instant. A system can be concurrent without being parallel, and the difference matters for how it actually behaves under load.
Long Polling vs WebSockets
WebSockets named long polling as the workaround it replaced, and promised the full head-to-head here. Both solve the same problem — getting server-originated updates to a client faster than repeatedly asking "anything new?" — but they solve it with a fundamentally different relationship to plain HTTP request/response.
Batch vs Stream Processing
Data eventually needs to be processed — aggregated, transformed, analyzed — and there are two fundamentally different ways to schedule that processing: gather it up and process it in large chunks on a schedule, or process each record continuously as it arrives. The choice shapes how fresh the results are, how much infrastructure is needed, and how the system behaves under a burst of data.
Stateful vs Stateless Design
HTTP/HTTPS and WebSockets both pointed here as the general form of a tension they each hit concretely: whether a server needs to remember anything about a specific client between requests. That single design decision — stateless or stateful — quietly determines how easily a service can be horizontally scaled.
Strong vs Eventual Consistency
Database Architectures and Change Data Capture both pointed here for the read-side consequence of replicating or propagating data across multiple places: once more than one copy of something exists, what can a reader actually rely on seeing? Strong and eventual consistency are the two ends of that answer.
Read-Through vs Write-Through Cache
Caching Strategies introduced cache-aside, write-through, write-behind, and read-through, and promised this dedicated head-to-head between the two "through" strategies specifically — the ones where the cache itself, not the application, owns talking to the database.
Push vs Pull Architecture
Webhooks and CDN both pointed to this lesson as the general pattern behind a specific choice they each make: does the side with new data send it out (push), or does the side that wants data go ask for it (pull)? Nearly every data-movement decision in this course is an instance of one of these two.
REST vs RPC
REST vs. GraphQL compared two ways of exposing data to a client. RPC (Remote Procedure Call) is a different axis entirely: instead of modeling an API around resources, it models it around actions — calling a named function on a remote service feels, as much as possible, like calling a regular function in your own code.
Synchronous vs Asynchronous Communication
This is the most general tradeoff in this entire module, and a fitting one to close on: does the caller wait for a response before continuing, or does it move on immediately and find out the result some other way, later? Nearly every specific pairing already covered in this course — long polling vs. WebSockets, push vs. pull, message queues vs. direct calls — is really this one underlying decision, applied to a particular piece of the system.