Integration Patterns Every Systems Analyst Should Know

Integration patterns are the small set of reusable ways systems talk to each other: request-response, messaging, publish-subscribe, request-reply, batch, and webhooks. Knowing them, and their trade-offs, is how a systems analyst reads and designs how systems connect.

Integration patterns are the reusable ways systems exchange data and trigger each other’s actions, and there are only a handful that matter: request-response for synchronous calls, messaging for asynchronous queues, publish-subscribe for one event consumed by many, request-reply over messaging, batch file transfer for bulk scheduled data, and webhooks for server-initiated callbacks. Each makes a different trade-off in coupling, latency, reliability, and failure handling, and a systems analyst who knows them can look at any integration and immediately understand its behavior, its failure modes, and its implications for the customer. The analyst who does not know them is stuck describing every integration from scratch and missing the failure modes the pattern would have warned them about.

In payments you see all of these in a single platform, often within one transaction: a synchronous call to accept a payment, an event published to many consumers, a webhook to notify a channel, and a batch file for end-of-day settlement. Recognizing which pattern is in play tells you what can go wrong and what the requirements must cover. This is core architecture literacy, and it builds on the boundary you draw in a system context diagram. The technical depth to reason about these patterns is mapped in The Technical Skills Guide for BAs.

Request-response: the synchronous default

Request-response is the simplest pattern: the caller sends a request and waits for an immediate reply. It is the synchronous API call everyone knows, and its strength is also its weakness. It is easy to reason about, you get an answer right away, but it couples the two systems tightly, so if the provider is slow or down, the caller is stuck waiting.

In a payment flow, accepting a payment is often request-response: the channel calls the engine’s POST /payments and waits for a 202 received. That immediacy is exactly what you want at the front door, where the customer needs to know their request was accepted. But notice the coupling: if the engine is slow, the channel hangs, and the customer waits. That is why systems rarely do the actual processing synchronously; they accept fast and process asynchronously behind the scenes.

The requirements implications of request-response are about timeouts and failure. What does the caller do when the provider does not respond in time? What does the customer see during a slow call? These are real requirements that the pattern itself raises, and missing them produces hung screens and confused customers. The full treatment of synchronous versus asynchronous trade-offs is in synchronous vs asynchronous, and specifying the call precisely is the API requirements work.

Messaging and publish-subscribe: decoupling with queues

Messaging decouples systems by putting a message on a queue that the receiver processes independently, and publish-subscribe extends that so one published event reaches many independent subscribers. These asynchronous patterns are the backbone of modern payment platforms, and they trade simplicity for resilience and scale.

With plain messaging, a sender drops a message on a queue and moves on; the receiver consumes it when it can. This means the sender is not blocked by a slow receiver, and the queue absorbs bursts of load. With publish-subscribe, a producer publishes an event to a topic, and any number of subscribers consume it without the producer knowing who they are. In payments, a single payment.posted event might be consumed independently by the ledger, a notification service, and a reporting service, each doing its own thing. The power is that you can add a new consumer, a fraud monitor, say, without touching the producer at all.

The cost is the hard part of distributed systems: events can arrive out of order, be delivered more than once, and be processed by consumers that update state independently, so the system is only eventually consistent. Every one of those is a requirement the pattern forces you to address, which is exactly the event-driven requirements discipline, and testing it directly is how to test Kafka. The independence of subscribers is also why a single event reaching a ledger and a notification service can produce the classic defect where the customer is notified before the ledger posts, a window you must design for.

Request-reply and webhooks: asynchronous, but you still get an answer

Sometimes you need a response but cannot afford synchronous coupling. Two patterns solve this: request-reply over messaging, where the answer comes back on a separate queue, and webhooks, where the provider calls you back over HTTP when it has a result. Both give you an answer without making the caller block.

Request-reply over messaging sends a request message and listens for a correlated reply message, tying the two together with a correlation id. The caller is not blocked the way a synchronous call would be, but it still eventually gets its answer. This suits longer-running operations where waiting synchronously would be impractical. Webhooks reverse the usual direction: instead of the consumer polling the provider for a result, the consumer registers a URL and the provider sends an HTTP request to it when the event happens. This gives near real-time updates over standard HTTP without the consumer hammering a status endpoint.

Both patterns push specific requirements. With webhooks, the consumer must handle retries and duplicates, because the provider will resend if it does not get a success acknowledgment, and must verify the call is authentic so an attacker cannot forge it. With request-reply, the caller must handle the case where the reply never comes. These are the failure-handling requirements that separate a robust integration from one that loses messages, and reasoning about them is the systems analyst job. The correlation-id discipline that makes request-reply traceable is the same one that makes end-to-end testing possible, as in You Don’t Understand the System Until You Test It.

Batch file transfer: the pattern that refuses to die

Batch file transfer moves large volumes of data on a schedule, usually as files, and despite decades of real-time enthusiasm it remains everywhere in banking. Use it when high volumes can be processed together and immediate processing is not required: end-of-day settlement, reporting, reconciliation files, bulk uploads.

The pattern is simple: one system produces a file of records, transfers it, and another system ingests and processes the whole batch. Its strengths are efficiency at volume and simplicity of reasoning, you process a known, complete set of data at a known time. Its defining weakness is latency: a record in the batch waits until the scheduled run, which is why some payments still feel slow and why a correction submitted after the cutoff waits until tomorrow.

For an analyst, batch raises a distinct set of requirements: what happens when the file is late or missing, how partial failures within a batch are handled, whether the batch is all-or-nothing or record-by-record, and how you reconcile the batch against the source. These are different questions than a real-time integration raises, which is exactly why the batch vs event-driven choice matters so much and why batch and real-time so often coexist in one platform. Reconciling batch outputs against expectations is the reconciliation design problem.

How a systems analyst uses integration patterns

You use integration patterns as a vocabulary for reading and designing how systems connect. When you encounter an integration, you identify its pattern, which immediately tells you its coupling, its latency, its failure modes, and the requirements it demands, without having to derive all of that from scratch each time.

This is leverage. Recognizing that an integration is publish-subscribe instantly raises the questions of ordering, duplicates, and consumer independence. Recognizing a webhook raises retries, duplicates, and authentication. Recognizing batch raises late files and partial failures. The pattern carries its own checklist of concerns, and an analyst fluent in the patterns asks the right questions automatically. When designing, the same fluency lets you choose the pattern that fits the need, request-response for the fast front door, publish-subscribe for the fan-out, batch for the bulk overnight job, rather than defaulting to whatever is familiar.

That ability to name the pattern and reach for its concerns is what distinguishes a systems analyst who designs robust integrations from one who documents fragile ones. It pairs with the boundary view of the system context diagram and the detailed message flows that show the patterns in action, and the domain knowledge to apply it in banking is the subject of Break Into Banking.

The takeaway

Integration patterns are the handful of reusable ways systems connect: request-response, messaging, publish-subscribe, request-reply, batch file transfer, and webhooks. Each carries its own trade-offs in coupling, latency, and reliability, and its own checklist of failure-handling requirements. Knowing them turns every integration from a puzzle into a recognized pattern with known concerns.

Learn the patterns, and you read and design system connections with the right questions already in hand. Start with The Technical Skills Guide for BAs and Break Into Banking, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Systems Analysis, Integration, Architecture, Microservices, Banking