Structural Styles

It's a design where data flows through a chain of independent processing steps called filters, connected by pipes. Each filter does one small job and hands its output to the next, like workers on an assembly line.

The client-server style splits an app into two roles: a client that asks for something (a request), and a server that has the data or logic and answers back (a response). The client initiates; the server waits and replies.

Calls only go downward: UI talks to business logic, which talks to data access. Data access never calls back up - that would tangle everything together, making each part impossible to change or test alone.

One app, one deployment, but cut into modules that hide their internals and only talk through defined entry points - unlike a folder-organized monolith where any code can still call any other code directly.

Inside a monolith, all the code runs in one program, so different parts call each other directly through normal function calls, instantly and without any network involved.

Every computer in the network can both ask for things and give things to other computers -- there's no single 'boss' machine. Each one shares data directly with others, like friends swapping items instead of going through a store.

SBA stores live data in memory across many machines instead of a single database, so a request never has to wait on one central database. That removes the database as the bottleneck when traffic suddenly spikes.

The contract is the fixed set of methods and data a plug-in must provide so the core can call it generically. Keep it small, stable, and versioned so new plug-ins can be added without changing old ones or the core.

Filters are composable because each one only cares about the data format coming in and going out, not about which specific filter is next to it. Keeping filters stateless and format-agnostic is what preserves that swappability.

Push means the upstream filter sends data downstream as soon as it's ready, like shoving items down a conveyor belt. Pull means the downstream filter asks for the next item when it's ready to handle it, like taking items off a shelf one at a time.

A stateless server treats every request independently and remembers nothing about the client between requests; the client must resend any context each time. A stateful server keeps track of a client's session (like being logged in) across multiple requests.

Leakage is when a layer's private details (like SQL, or UI formatting) show up inside another layer. Repeat that across a codebase and layers stop meaning anything - everything depends on everything, and nothing can change alone.

Strict layering: each layer can only call the layer directly beneath it. Relaxed/open layering: a layer may call any lower layer, skipping ones in between. Strict is safer but more boilerplate; relaxed is faster but easier to tangle.

Billing should call a small public interface (or listen to an event) that orders exposes on purpose - not reach into orders' database code - because reaching into internals means any change inside orders can silently break billing.

One build, one thing to deploy — simple and predictable. But if you only changed one small piece, you still have to rebuild, retest, and redeploy the whole app, and unrelated failures can block your release.

Gossip is how peers spread news the way rumors spread in a crowd: each peer periodically tells a few random other peers what it knows, and they tell a few more, until eventually almost everyone has heard it -- no one broadcasts to everyone at once.

An overlay network is a map of which peers talk to which, layered on top of the real internet. 'Structured' means peers are organized in a strict pattern so you can find things quickly and predictably; 'unstructured' means connections are more random, so finding things means asking around and hoping.

Replicated means every node has a full copy of all the data — fast reads everywhere but limited by how much fits on one machine and slower writes. Partitioned means each node holds only a slice — you can hold way more data total, but reads/writes for data you don't hold need a network hop.

A processing unit is a self-contained package of business logic plus its own slice of in-memory data plus the engine to run it — like a mini self-sufficient server. Bundling them means you scale by cloning whole units, not by separately scaling app servers and a database.

Splitting features into plug-ins means one broken or slow feature is less likely to crash everything else, and features can be updated separately. The cost is extra complexity: indirect calls are slower and different plug-ins can need conflicting versions of the same library.

When the pipe fills up because the consumer can't keep up, you either make the producer wait (slows the whole pipeline), throw away some data (loses it), or let the buffer grow (risks running out of memory). Each choice trades speed, correctness, or memory.

Multi-tier splits the server side further: instead of a client talking straight to a database, you add a middle layer (an application server) between them, so presentation, business logic, and data each live in their own layer.

Automated build-time checks - tools that scan the code's package/module structure and fail the build if, say, a UI package imports a database package. This catches violations every time, unlike relying on humans remembering the rule during review.

If a module only talks to others through its public API/events and doesn't share its database tables, you can swap that in-process API for a network call with far less risk - but if it secretly shares tables or needs instant answers from another module, extraction breaks things until you fix that first.

Because both billing and reporting directly use the same shared class in the same codebase, a change one team makes can silently break the other team's code, unlike separate services which only talk through a stable, agreed-upon interface.

Every peer and every piece of data gets a number. Each peer only directly knows a few other peers, chosen so at each step you jump about halfway closer to the number you're looking for -- like narrowing down a phonebook by splitting it in half each time, so it only takes a handful of hops even in a huge network.

Write-behind means the system says 'saved' as soon as data hits memory, then writes to the real database later in the background. If the machine crashes before that background write happens, that data can be lost — so systems copy it to a backup machine first.

The core scans for plug-ins, reads their info, loads their code, calls an init/start hook, and adds them to a lookup table the core uses to find them by name. Unloading reverses this: stop the plug-in, free its resources, remove it from the table.

A thin client does almost no work itself — it just displays what the server sends and forwards user input back. A fat (thick) client does a lot locally — business logic, validation, rendering — and only talks to the server for shared data or authoritative operations.