Architecture Grab-Bag & Picking Tech

A webhook is a callback: instead of consumers repeatedly asking "anything new yet?", the server calls them when an event actually happens. Picture an API serving exclusive baseball events, consumed by many third-party services. If each one keeps polling to check whether an event occurred, the constant requests pile unnecessary load on the server and can bring it down — and consumers have no way to know new data isn't ready yet, so they just keep asking.

Webhooks flip that with an event-based mechanism and enable communication between two services without middleware. How it works:

1. Register an endpoint. The consumer registers an HTTP endpoint with the service, along with a unique API key — like leaving a phone number: "call me here when something happens."
2. Server fires on the event. When new information appears on the backend, the server fires an HTTP event to every registered endpoint, notifying them of the update.

Browser notifications are the everyday example — instead of you revisiting a site to check for new content, it notifies you when it publishes.

Shared-nothing architecture is a design where modules share no resources — not RAM (shared memory), not disk (a shared database), nothing. When several modules work together they often share memory and share the database; a shared-nothing system deliberately gives every module its own memory and its own disk.

The payoff is the elimination of all single points of failure: if several modules go down, the others stay unaffected, which helps both scalability and performance. (You've already met this idea in the course — Cassandra's peer-to-peer nodes are a shared-nothing design.) [+]

A peer-to-peer (P2P) network lets computers (nodes) communicate directly with no central server — every node has equal rights and acts as both client and server. It's the base of blockchain tech, and you've used it via torrents. Each node is simultaneously a seeder (hosts data, uploads bandwidth to the network) and a leecher (downloads data). With no central server there's no single point of failure — even if some nodes go down, the network stays up.

Why centralization hurts

A central server (like a messaging app's) routes every message through the hosting organization. The course flags three downsides:

• Privacy. The central server sees all your messages; admins can read or share them, breaches happen, governments can request data, and it can be sold to third parties. Not truly secure.
• Fragility. Natural disasters, infrastructure failure, or the company going out of business leaves you unable to communicate.
• Control. Build a following on a platform and the company can delete your data on a whim — a real risk for content creators.

P2P's decentralized architecture is resilient to all three: no one controls or can delete your data, because every node has equal rights. It also shines for large file sharing — instead of messenger size limits, costly cloud uploads, or couriering DVDs, you share a torrent (e.g. via BitTorrent, the most common P2P protocol, ~25M concurrent users) and friends download while re-hosting.

P2P runs an overlay network over TCP/IP that lets users connect directly and handles the heavy lifting; nodes are indexed and discoverable in it. A large file is split into equal-size chunks transferred in non-sequential order — a node downloading a 75GB file grabs chunks and re-hosts each as it arrives, making it more available (segmented P2P file transfer ). Networks come in three flavors:

Decentralized social networks run on servers spread across the globe, hosted by individuals — nobody has autonomous control, everybody has an equal say. Their scalability is directly proportional to the number of active users joining, so they don't hit the usual scaling walls. You host your own data instead of shipping it to a third-party server, so no one eavesdrops or modifies it at will. If BYOD is "Bring Your Own Device," this is Bring Your Own Data: the user-data layer is separate and runs on decentralized-web protocols with consistent formats across apps — so leaving a network doesn't kill your data; you carry it to the next app. Active examples: Minds, Mastodon, Diaspora, Friendica, Sola.

ActivityPub is an open decentralized social-networking protocol — it provides an API to access/modify content and to communicate with other pods in the federation, which leads directly into the next pattern.

Federated architecture is an extension of decentralized architecture — a group of semi-autonomous entities that exchange information with each other. The real-world analogy: states run by state governments are partially self-governing, and they share information with each other and a central government to form a complete whole. It powers Mastodon, Minds, and Diaspora, though the model is still under active research with no standard rules.

In practice, a federated network has entities called servers or pods. Many nodes subscribe to a pod; multiple pods across the network link and share information, and individuals can host new pods — so the network keeps growing. If a link between pods breaks temporarily, the network stays up because nodes still reach each other through the pods they subscribe to.

There's no rule that use case X demands technology Y — every use case has unique needs, there's no silver bullet, and everything has trade-offs. With that caveat, the course maps standard use cases to fitting backend tech:

The meta-advice: once you start researching a technology and read its developer docs, one thing leads to the next — you'll discover the surrounding concepts and tools you need to implement your use case.

Picking the stack is crucial and hard to reverse once you're coding — the author frames these as a decade's worth of lessons learned the hard way (wasted months, unsupported tech, "crying into a pillow"). Six factors:

1. Be thorough with the requirements. You can't pick the right tech while unclear on what you're building. Know whether data is relational, document-oriented, or unstructured; whether it'll grow exponentially or stay bounded; whether a monolith fits or you need modules. Splitting into modules with heterogeneous tech gives you an escape hatch if one technology doesn't work out.
2. See if what you already know fits. Building with familiar tech skips the steep learning curve — you know the errors, exceptions, and fixes, so you ship faster. Don't chase shiny new toys or fall for hype until you truly need them; a novel exception with no answer online leaves you stranded.
3. Check the community, docs, and support. An active community (GitHub, StackOverflow) means updated tools, libraries, and frameworks, plus help when you're stuck. Documentation should be smooth; official support is a bonus. Bigger community = better.
4. Is it used by big guns in production? If major companies run it in production, it's battle-tested — you're less likely to hit inherent scalability, security, or design issues, since the codebase is continually patched by the owner and those companies' engineers.
5. Check the license — is it open source? Open source lets you write custom features instead of waiting on the creator, costs no fees, and has a larger community since anyone can fork, extend, or fix it.
6. Are skilled people available? As you grow you'll need to hire and move fast. It's far easier to find a MySQL admin or Java developer than a specialist in a newer, niche technology.

These two chapters cite two external links. One resolves live; the other blocked automated access and is omitted (noted in the footer).