Structural Styles

Instead of grouping all controllers together, all services together, all repositories together, you group everything one feature needs into a single place, so changing that feature means touching one folder, not five.

OSGi is a Java framework where 'bundles' are the plug-ins and a service registry is the core. Eclipse's IDE core is the workbench/editor shell, and plug-ins add languages, tools, and views. A rule engine's core evaluates rules against facts, and each rule is the swappable unit.

Pipes and Filters is great when work is a straight-line sequence of transformations on a stream of data. It's a bad fit when steps need to talk back and forth, share complex state, or when the order of work depends on business rules that don't map to a simple chain.

HTTP is built as a request-response protocol: a browser or app (client) sends an HTTP request to a URL, and a web server responds with data or a status. REST is a set of design rules on top of HTTP saying, among other things, each request must be self-contained (stateless) and resources should be handled through a uniform set of methods like GET/POST/PUT/DELETE.

A sinkhole is when a layer just passes a call straight through to the layer below without adding anything - no logic, no transformation, just forwarding. Lots of sinkholes mean the layering is adding busywork without adding value.

With a small team and an unproven product, a monolith is faster to build, deploy, and change, and there's no clear reason yet to split it up. You'd reconsider once specific parts need different scaling, release cadence, or separate teams.

Peers come and go all the time in a P2P network, like people wandering in and out of a crowd. If the network doesn't keep updating its 'who's near whom' info and doesn't keep spare copies of data on multiple peers, searches start failing and data can vanish when the one peer holding it leaves.

The messaging grid is the traffic router — it sends each incoming request to the right processing unit and keeps everyone's data in sync as machines are added or removed on the fly, without stopping the system.

Layered architecture struggles when a system needs very low latency (extra layers add delay), or when features naturally cut across many capabilities rather than through one tech stack. In those cases, teams often use event-driven, microservices, or feature-sliced designs instead.

It's the wrong pick mainly when a domain is still changing shape fast, so boundaries would be guessed wrong and redrawn constantly, or when different parts genuinely need very different scaling/tech - and even a well-built one can rot years later if governance around the enforcement rules quietly weakens.

It's a bad fit when data is too big to fit affordably in memory, when you need strict, immediate correctness guarantees everywhere (like banking transfers), or when your load is steady rather than bursty — you'd be paying a lot of complexity and memory cost for a benefit you don't actually need.

Plug-in systems can fail in tricky ways: a plug-in crashing the whole app if isolation is weak, version conflicts between plug-ins, and slow startup as plug-ins pile up. Skip this pattern if you don't actually have many independent, optional features.

You need a way to know exactly where the pipeline got to when it crashed, so you can restart safely instead of redoing everything (which can duplicate data) or skipping ahead blindly (which can lose data). The main tools are checkpoints, making each step safe to repeat, and hiding half-finished batches from readers.

Plain client-server needs the client to reach the server for almost everything, so if the network is down for hours, a naive client-server design just stops working. The fix is to let the client keep a local copy of data and logic so it can operate offline, then sync with the server once the connection comes back.

Run many identical copies of the app behind a load balancer, plus a stronger or split-up database. This works until the shared database, or one hot feature, can't keep up no matter how many copies you run.

A Sybil attack is when one person pretends to be hundreds or thousands of different peers using fake identities. If enough fake peers surround the part of the network responsible for a specific piece of data, the attacker can quietly control access to that data or hide it, since new peers only trust who the network tells them to trust.