Batch file exchange between systems via shared file system or FTP/SFTP. Asynchronous, decoupled, simple. Large data volumes efficiently transferred. One system writes file, another reads. Common formats: CSV, XML, JSON, EDI. File naming conventions with timestamps. File processing acknowledgment. Polling directory for new files. Scheduled batch processing (nightly, hourly). Simple but lacks real-time capability. Mainframe-to-cloud migrations often start here.

Multiple applications access common database. Tight coupling through shared schema. Immediate data availability. No network calls between apps. Schema changes affect all systems. Concurrency and locking concerns. Encapsulation violated (direct data access). Performance bottleneck on database. Legacy integration pattern. Difficult to version independently. Prefer for tightly coupled modules, not distributed systems. Often anti-pattern in microservices.

Synchronous request-response communication. Calling remote method appears local. gRPC, Apache Thrift, SOAP, XML-RPC. Strong typing with protocol buffers or WSDL. HTTP/2 for gRPC performance. Blocking calls, caller waits for response. Tight temporal coupling. Network failures appear as method failures. Timeouts essential. Service meshes for observability. Client and server tightly coupled on interface. Suitable for low-latency internal services.

Asynchronous event-driven communication via message broker. Producers send, consumers receive independently. Temporal decoupling (systems don't need to be up simultaneously). Message queues (point-to-point) or topics (pub/sub). RabbitMQ, Apache Kafka, AWS SQS/SNS, Azure Service Bus. At-least-once, at-most-once, exactly-once semantics. Enables event-driven architectures. Scalable and resilient. Message ordering considerations. Eventual consistency patterns.

Choosing integration approach based on requirements. File transfer: batch, large volumes, legacy systems. Shared database: tight coupling acceptable, single team. RPC: synchronous, low latency, request-response. Messaging: asynchronous, decoupled, event-driven. Consider: latency needs, coupling tolerance, scalability, failure handling. Hybrid approaches common (API for queries, events for updates). RESTful HTTP for external, messaging for internal. Saga pattern combines sync and async.

Combining synchronous and asynchronous patterns. API request triggers, async processing via queue, callback on completion. Command via API, events via messaging. CQRS: sync commands, async query model updates. Request-acknowledge-callback pattern. Webhook for async notifications. Long-running operations: accept request (202), poll status endpoint, push notification when done. Balances user experience (sync) with scalability (async). Saga pattern spans sync/async boundaries.

Field-level transformation and mapping between formats. Source schema to target schema. Handles renaming, type conversion, restructuring. Visual mapping tools (Mulesoft DataWeave, XSLT). Declarative transformations. Nested object mapping. Array transformations. Expression language for logic. Version management for mappings. Schema evolution handling. Enterprise integration tools provide mappers. Can be code or configuration.

Enterprise-wide common message format. All services translate to/from canonical model. N integrations instead of N². Reduces point-to-point complexity. Common vocabulary and semantics. Schema management challenge. Services maintain adapters to canonical. Versioning canonical model difficult. Can become enterprise bottleneck. XML Schema, JSON Schema, Protobuf for canonical. Alternative: context-specific models with anti-corruption layers.

Converting between system-specific formats. Adapter pattern for messaging. Each system speaks own language, translator converts. XML to JSON, SOAP to REST, Protobuf to JSON. Protocol conversion. Legacy system integration. Translation layer between bounded contexts. Apache Camel Type Converter. AWS EventBridge transformers. Can be stateless or stateful. Often combined with routing.

Adding metadata without modifying payload. Wrap message with routing info, security context, tracing headers. Original message preserved. Headers for routing, filtering. Correlation ID, timestamp, source. JWT token in wrapper. CloudEvents specification. Kafka message key and headers. Enables cross-cutting concerns without payload changes. Unwrap at destination. Layer 7 envelope for layer 7 payload.

Augmenting messages with additional data. Lookup related data from external sources. Add customer details to order message. Geocode address in shipping message. Enrich with real-time data (stock price, weather). Call external API synchronously. Query database for reference data. Cache for performance. Stateless transformation. Apache Camel Content Enricher. Keeps publishers simple. Risk: enrichment failure blocks processing.

Storing large payloads externally with reference tokens. Message contains claim check (ID or URL). Receiver retrieves payload using claim check. Reduces message size in broker. Keeps queues lightweight. Store in S3, blob storage, database. Claim check expires after TTL. Useful for images, videos, large documents. Decouples message transport from payload storage. Kafka with large messages uses this. Trade-off: extra hop to retrieve.

Periodic message retrieval from queue. Consumer checks for messages at intervals. Pull model. Simple implementation. Control consumption rate. Works with REST APIs (long polling). SQS polling, database polling. Configurable poll interval. Inefficient for low message rates. Delay between message arrival and processing. Good for batch processing. Spring Integration poller. Can miss messages if not careful.

Push-based message delivery. Broker pushes messages to consumer. No polling overhead. Immediate message processing. Callback or listener pattern. RabbitMQ push, Kafka consumer poll (but push-like). WebSocket, Server-Sent Events for browser. AWS Lambda triggers. Low latency. Requires consumer to be always available. Backpressure handling important. Reactive streams. Prefetch and buffering. Acknowledges messages after processing.

Load distribution across multiple consumers. Multiple instances consume from single queue. Message delivered to one consumer only. Horizontal scaling of message processing. RabbitMQ work queues, SQS multiple consumers. Partition-based in Kafka (one consumer per partition). No message duplication (within partition). Increases throughput. Failure of one consumer doesn't stop processing. Consumer groups. Auto-scaling based on queue depth.

Distributing work to specialized processors. Single consumer receives, dispatches to handlers. Handler per message type or command. Command pattern implementation. Spring @MessageMapping annotations. Switch statement anti-pattern vs strategy. Polymorphic dispatch. Actor model dispatching. Reduces code duplication. Central routing logic. Extensible for new message types. Alternative: separate queues per type.

Message filtering at consumer level. Consumer specifies filter criteria. JMS message selectors. Kafka consumer filters (client-side). SQL-like expressions for filtering. Subscribe to subset of messages. Reduces unnecessary message delivery. Can be inefficient (broker still sends). Better: broker-side filtering or topic design. Use when consumer needs dynamic filtering. Combine with message filter pattern.

Handling duplicate message delivery safely. At-least-once delivery causes duplicates. Detect and skip duplicate processing. Deduplication using message ID. Store processed IDs (database, cache). Time-window deduplication. Idempotent operations naturally safe (update operations). Non-idempotent needs explicit handling (payment processing). Kafka exactly-once with transactions. SQS message deduplication. Essential for reliable messaging. Idempotency keys in APIs.