Messaging & Integration

The server says 'got it, working on it' right away instead of making the client wait. It hands back a link the client can check later to see if the work is done. This keeps the connection short and frees the client to do other things while it waits.

Several worker programs all watch the same queue and grab the next job when free. This lets jobs get done faster (more workers = more parallel work) and keeps things running if one worker crashes.

It puts one gateway in front of many services. The gateway makes all the backend calls itself and sends the client one combined response, so the client needs only one request instead of many slow round trips.

The gateway holds the certificate and does the encryption handshake once, so backend services get plain, already-decrypted traffic instead of every service needing its own certificate and crypto work.

A routing gateway is one front door for many backend services. It reads each request (like the URL path) and forwards it to the right service, so callers only need to know one address, not every internal service location.

You break a big job into small steps, each done by its own worker (a filter). The workers pass data to each other through a queue (a pipe). Each worker only does one thing, so you can reuse, replace, or scale each step on its own.

It lets a system handle important messages before less important ones — usually by giving each priority level its own queue — so urgent requests aren't stuck waiting behind a big batch of routine work.

Each service owns its own database, so one transaction can't span them all. A saga runs a sequence of local transactions instead, one per service; if a later step fails, it runs compensating actions to undo the already-completed earlier steps.

You build three parts: a front door that speaks your new system's language, a connector that knows how to call the old system, and a converter that maps data between the two. A request goes in the front door, gets converted, sent to the old system via the connector, and the response gets converted back.

The status endpoint should say 'still working' while the job runs, then either hand back the finished result or an error once it's done, and it can include a hint about how long to wait before checking again.

The system can't perfectly promise a message is handled exactly one time — crashes and retries mean it might get handled twice. So the code that processes a message has to be written so doing it twice causes no harm, like setting a value instead of adding to it.

It's a timer that hides a message from other workers while one worker is handling it, so two workers don't do the same job. If the timer's too short, someone else grabs it early and it gets done twice. Too long, and a crash leaves it stuck.

Calling each service one after another means the gateway waits for all of them added together, which is slow. Fixing it means starting all three calls at roughly the same time and only waiting once, so the total wait is about as long as the slowest single call.

The gateway checks the caller's token or API key once, and if it's valid, forwards the request to the backend with a header saying who the caller is, so the backend trusts that header instead of re-checking credentials itself.

The gateway can send a slice of traffic, or all of it after a flip, to a new version instead of the old one, just by changing routing rules. Clients never need to change since they call the same address.

A gateway can look at the URL path, hostname, a header, or a query parameter to pick a backend. Path routing is visible in the URL; header routing is hidden, so it needs the client to cooperate.

The slow step's input line piles up with waiting work, like a checkout line behind a slow cashier. Fix it by giving that step more workers, making it faster, or limiting how fast work is fed into it.

You can either make several separate queues (one per priority level) and check the important ones first, or use one queue on a broker that supports priority natively and lets it sort messages itself. The first is simpler to set up anywhere; the second is neater but ties you to that broker's limits.

In choreography, each service listens for events and decides what to do next itself - no central boss. In orchestration, one coordinator service tells each step what to do and waits for the result, like a conductor directing an orchestra.

A good compensating action produces the opposite business effect (like a refund for a charge), not a literal undo, because by the time you need to compensate, other systems may have already seen and acted on the original change.

Let the client attach a unique 'idempotency key' to its request; if it retries after a timeout, the server recognizes the same key and returns the existing job instead of starting a new one. Beyond that, watch out for stuck jobs, crashed workers, and clients polling forever.

Aggregation adds an extra hop, an extra thing to build, run, and version, and makes the whole response only as fast as the slowest call inside it. If services are already fast and nearby, or clients need very different, fine-grained data, forcing everything through one big aggregator can do more harm than good.

The gateway counts how many requests each client has made in a time window and blocks them once they go over the limit. If there are several gateway machines each counting on their own, a client can sneak past the real limit by spreading requests across them.

Every request now takes an extra hop through the gateway, adding latency, and the gateway itself must stay up and correctly configured or nothing behind it is reachable. Not worth it for a tiny system with one or two services.

The queue doesn't know the work finished, so it hands that message to someone else too — meaning it might get processed twice. Filters need to be written so doing the same work twice causes no harm (like setting a value, not adding to it).

Even though the messages were split into two queues, they still shared the same workers and the same database — so when the low-priority ones went haywire, they used up all the shared capacity and slowed down the important ones too. True isolation means separating the resources, not just the queues.

2PC locks all the databases involved and either commits everyone at once or nobody, giving true atomicity but requiring everything to stay locked and online together. Sagas skip the locking - each step commits on its own - trading that strict atomicity for services staying independent and available, using compensations instead of guaranteed rollback.

It costs extra code, extra testing, and a bit of speed to build and maintain the translator. It pays off by keeping your own system clean and easy to change even if the outside system is messy or changes later.

Only fail the whole response if a truly required piece of data is missing. For optional extras like recommendations, return the page without that section, or with a placeholder, rather than blocking the whole page on a non-critical service.