Distribution Styles

A coarse-grained SOA service bundles a whole business capability (like 'Order Management') behind one interface, instead of splitting into many tiny services, so fewer calls and less network chatter are needed.

An ESB is a central piece of middleware that routes, translates, and sometimes transforms messages between services, so services don't need to know how to talk to each other directly - but if too much logic piles into it, it becomes a slow, fragile bottleneck everyone depends on.

WSDL is an XML file describing exactly what operations a service offers, what data it expects and returns, and how to reach it; SOAP is the XML message envelope used to actually call it. Together they make the contract very strict and machine-checkable, unlike looser REST/JSON APIs.

SOA and microservices both break a system into services, but SOA services usually share a central ESB and shared data model and are governed centrally, while microservices talk more directly and are owned independently. Still, SOA's core idea - build a system as loosely coupled services with contracts - is the same idea microservices inherited and refined.

A canonical data model is one shared, agreed-upon 'master' format for a business concept (like Customer or Order) that every service translates to and from, so many different systems don't need a custom translation for every other system.

A microservice can be built, tested, and released on its own, without redeploying other services at the same time. This is the core feature that lets teams move fast without waiting on each other.

Grouping a service by business area (like 'Payments' or 'Inventory') keeps everything that changes together in one place. Splitting by technical layer instead means one small business change touches many services at once, which is slow and fragile.

Failure isolation means if one small service crashes or slows down, the rest of the system keeps working instead of everything going down together. It requires the other services to handle that failure gracefully instead of just waiting forever or crashing too.

Different services can use different types of databases -- like a graph database for recommendations and a plain SQL database for orders -- because each service picks the storage that best fits its own data, instead of everyone being forced onto one shared database.

This is called a 'distributed monolith' -- many separate services that still have to be released together and share data directly. It gives you all the extra network calls and complexity of microservices, but none of the benefit of teams shipping independently.

A producer creates and sends out an event (like 'something happened') without knowing who's listening. A consumer picks up events it cares about and reacts. Neither needs to know the other exists directly.

Broker topology: services react to an event directly, no one's in charge, like everyone hearing an announcement and acting on their own. Mediator topology: one central coordinator listens first and tells each service what to do, in order.

The sender and receiver don't have to be online or ready at the exact same moment. The event waits until the receiver is ready to handle it, unlike a phone call where both sides must be on the line together.

The user is waiting right there for an answer. Event-driven flows don't promise a fast, in-order response, so making them wait for a broadcast-and-hope-someone-answers pattern is the wrong tool — a simple direct call that returns the answer is simpler and faster here.

The system says 'done' before every related piece of data actually catches up — it becomes correct everywhere a little later, not instantly. If something checks inventory in that gap, it can see stale, wrong numbers.

BaaS means renting ready-made backend pieces (login, database, notifications) from a vendor's cloud instead of writing and running your own server code and infrastructure for each of them.

A cold start is the extra delay when a serverless function runs for the first time (or after being idle) because the cloud provider has to set up a fresh container and boot the code before it can process the request, instead of reusing one that's already running.

You pay for two things: how many times your function ran (per request), and how much compute it used each time (memory allocated multiplied by how long it ran, in GB-seconds). No traffic means no bill.

Push: the source (like an API Gateway) calls the function immediately for each request, so it runs right away. Poll: the platform itself checks a source (like a queue) on a timer, gathers waiting messages, then invokes the function with a batch.

A cold start is when the cloud has to build a fresh environment to run your function, which takes extra time. A warm start reuses an environment left over from an earlier call, so it responds almost instantly.

JS mount loads the microfrontend's code into the same page so it shares the DOM and can talk to other parts easily. An iframe loads it as a separate mini-webpage inside a box, fully isolated but harder to communicate with.

A host is the app that loads pieces from other apps; a remote is the app that shares its pieces. Webpack lets the host fetch and run the remote's code straight from the browser, without both being built together.

Path-based routing uses the real URL path and needs server/CDN config to serve the app for every path; hash-based routing puts the route after a # so the browser never asks the server for it, but it looks less clean and hurts SEO.

Build-time means you bake all the pieces together into one app before you ship it, like baking ingredients into one cake. Runtime means the browser loads separate pieces live, like assembling a meal from dishes served at the table.

Singleton means every microfrontend uses one shared copy of a library loaded once on the page. Scoped means each microfrontend ships and uses its own private copy. Singleton saves download size but couples apps; scoped isolates apps but repeats code.