Enterprise Integration Patterns for AI
Core Architecture
graph TD
subgraph "Synchronous Pattern"
S_CLIENT["Client"] -->|"REST / gRPC"| S_AI["AI Service"]
S_AI -->|"Response < 5s"| S_CLIENT
S_AI -.->|"Timeout"| S_FALLBACK["Fallback Response\n(default / degraded)"]
end
subgraph "Asynchronous Pattern"
A_CLIENT["Client"] -->|"Submit request"| A_QUEUE["Message Queue\n(Kafka / SQS)"]
A_QUEUE --> A_WORKER["AI Worker"]
A_WORKER --> A_RESULT["Result Queue"]
A_RESULT -->|"Webhook / Poll"| A_CLIENT
end
subgraph "Batch Pattern"
B_TRIGGER["Scheduler\n(Airflow / cron)"] --> B_LOADER["Batch Loader\nPartitioned dataset"]
B_LOADER --> B_AI["AI Workers\n(parallel)"]
B_AI --> B_SINK["Output Store\n(Data warehouse / EHR)"]
end
Common Mistakes
1. Using synchronous calls for long-running AI operations. A 30-second AI response on a synchronous call holds an HTTP connection and a thread for the entire duration. Under load, this exhausts connection pools and cascades failures to the calling system.
2. Not implementing fallback for synchronous AI calls. If the AI service is unavailable and the calling system has no fallback, the calling system fails too. For clinical systems, the fallback must be defined before the feature is deployed.
3. No idempotency in async workers. A Kafka consumer that processes the same message twice writes two AI-generated documents to the EHR. Every async AI worker must check whether a job_id has already been processed before executing.
Key Takeaways
- The integration pattern (synchronous, asynchronous, batch) must be selected before the AI model, because it determines end-to-end architecture
- Synchronous AI integration requires explicit timeout and fallback behavior; the AI system must never take down the calling system
- Asynchronous AI integration requires idempotent workers and dead letter queues
- Batch AI integration requires checkpointing for resumability on large datasets
- PHI handling requirements apply to all three patterns: encryption in transit, audit logging, least-privilege access