Communication & Data Management

A BFF is a small backend built just for one type of app (like a mobile app or a website) so that app gets exactly the data it needs in one call, instead of talking to lots of different services itself and stitching the results together.

A synchronous call waits for an immediate answer before moving on, like a phone call. An asynchronous message is sent off while the sender keeps working, like leaving a voicemail; the other side handles it and replies whenever it's ready.

A backward-compatible change lets old clients keep working without updates, like adding a new optional field. A breaking change forces every client to update at once, like renaming or removing a field they depend on.

Each service gets its own database so only that service can change its data directly; others must ask through its API, which stops hidden dependencies and lets services evolve independently.

A saga splits one big transaction into small local ones, each service commits its own piece right away; if something later fails, earlier steps are undone with a follow-up 'undo' action instead of everyone waiting and locking together like 2PC.

The gateway checks the caller's login token once, before the request goes anywhere else. If it's valid, the gateway lets the request through and tells the backend service who the caller is; if not, it rejects the request immediately.

The gateway keeps a running count of how many requests each caller has made recently. Once a caller crosses the limit, the gateway rejects further requests for a while instead of forwarding them, protecting the backend services from being overwhelmed.

The BFF talks to the same backend services either way, but it sends the mobile app a smaller, simpler bundle of data (fewer fields, smaller images) and sends the web app a fuller bundle, because phones have less screen space and often slower or costlier networks.

Request/reply is one service asking another a direct question and getting a direct answer, like calling a specific person. Publish/subscribe is one service announcing something happened, and any number of other services that care can listen in, like posting an announcement on a notice board.

Each consumer writes down exactly what it expects from a provider's API. The provider runs those expectations as tests before deploying, catching breakage early without needing a slow, flaky full end-to-end environment.

Either Service A asks Service B live every time it needs the data (simple but creates a runtime dependency), or Service A keeps its own local copy that's kept up to date via events (fast and independent, but the copy can be briefly out of date).

A read model is a service's own local, search or query-optimized copy of data that another service owns, kept updated by listening to that service's change events, so it can answer queries fast and independently instead of calling the owner every time.

Choreography: each service listens for events and reacts on its own, no one's in charge. Orchestration: one central coordinator tells each service what to do next, step by step.

If a service saves to its database and separately sends a message, one can succeed while the other fails, leaving things out of sync. The outbox pattern saves the message in the same database transaction as the data change, then a separate process reliably delivers it, so both always happen together or neither does.

Instead of the client making five separate calls to five services, it makes one call to the gateway, and the gateway calls all five services itself, combines the answers, and sends back one response. The risk is that the slowest of those five calls determines how long the client waits, and if any one fails, the whole combined answer can fail too.

A shared gateway is one door for every app; a BFF is a separate, tailored door per app. The shared-gateway approach breaks down when different apps need very different data shapes and change at different speeds, because now every client's feature work has to queue behind the one team that owns the shared door.

Choreography is like a dance where everyone reacts to what everyone else does, with no one in charge. Orchestration is like a conductor telling each musician exactly when to play. Choreography has no single controller; orchestration has one service driving the whole process.

You can put the version in the URL path, in a request header, or in a query parameter. URL versioning is the simplest and most visible; header-based versioning keeps URLs stable but is less discoverable. All of them mean you're running and maintaining more than one version of your API at once.

REST with JSON is simple, human-readable, and works everywhere, including browsers, but is slower to parse and less strict about structure. gRPC uses a compact binary format and a strict contract, making it faster and safer between services, but harder to read by hand and not natively usable from a browser.

A tolerant reader only looks at the specific fields it actually needs from a response and ignores everything else, so it doesn't break when the provider adds new fields or extends the data it sends.

If the gateway just waits and waits for the slow service, it uses up all its capacity holding open those slow requests, leaving nothing free to handle requests to other, healthy services. A circuit breaker makes the gateway stop sending requests to the slow service for a while so it can recover and free up capacity for everything else.

Frontend teams can ship changes fast without waiting on a separate backend team, since they own their own small backend. But over time, each team's BFF often quietly reimplements the same business rules, and those copies drift apart until different apps disagree with each other.

C being slow makes B slow, which makes A slow too, and if nothing stops it, all three can eventually run out of capacity and fail together, like one traffic jam backing up onto every road behind it. Fixes include setting time limits, giving up early instead of piling up more requests, and having a backup plan when the answer doesn't come.

A schema registry checks new versions of a data format before allowing them to be published, using rules like 'can old readers still read new data' (forward) or 'can new readers read old data' (backward), and 'full' means both must hold at once.

If a service saves to its database and then separately sends a message, one of those two steps can fail after the other succeeds, for example the app crashes right between them, leaving the database and the message out of sync. A common fix is to write the event into the same database transaction as the data change, then have a separate process reliably forward it.

A compensation is a new action that semantically cancels an earlier step, not a database undo. It's easy when the earlier step is fully reversible (like un-reserving stock); it's hard or impossible when the earlier step already had a real-world, external, or irreversible effect, like an email that was already sent or money that already left the system.

The consumer keeps a record of which message IDs it already processed, in the same database transaction as the work it does. If the same message shows up again, it checks that record first and skips redoing the work, so a duplicate delivery has no extra effect.

Nginx is a fast general-purpose proxy you configure and run yourself; Kong adds API-specific features (plugins for auth, rate limiting) on top of that same self-hosted model; AWS API Gateway is a fully managed service with those features built in but tied to AWS. Sometimes it's better NOT to force all traffic through one shared gateway, especially service-to-service traffic inside the system.

With only one app and one small backend, there's nothing to tailor a response for and no second team that needs independence - a BFF here just adds an extra network hop and another service to run, for no real benefit yet. Add it later, once there are genuinely different clients or teams pulling the API in different directions.