Diagrams

Every figure, on one page.

The 48 diagrams from Enterprise Integration Patterns with Apache Camel, in reading order. Each one renders inline here and ships a paired .excalidraw source you can open on excalidraw.com and edit.

Diagram showing the five shipping domain services and the Kafka event flow between them
Figure 1.1: The shipping domain order flow

Download .excalidraw source Edit on excalidraw.com

Diagram showing the local infrastructure stack: Kafka, Pulsar, Redis, PostgreSQL, Apicurio, and the LGTM observability overlay
Figure 1.2: Local stack architecture

Download .excalidraw source Edit on excalidraw.com

Diagram showing the four integration styles side by side: File Transfer, Shared Database, RPI, and Messaging
Figure 2.1: The Four Integration Styles

Download .excalidraw source Edit on excalidraw.com

Diagram showing the six messaging system building blocks and how they relate
Figure 3.1: The six building blocks of a messaging system

Download .excalidraw source Edit on excalidraw.com

Pipes and Filters pattern
Figure 3.1: Pipes and Filters, each filter transforms the message

Download .excalidraw source Edit on excalidraw.com

Point-to-Point vs Publish-Subscribe channel types
Figure 4.1: Point-to-Point delivers to one consumer; Publish-Subscribe delivers to all consumer groups.

Download .excalidraw source Edit on excalidraw.com

Kafka topic with 3 partitions, each assigned to exactly one consumer in the inventory-service consumer group
Figure 4.1: Point-to-point via Kafka consumer groups: each partition is assigned to exactly one consumer instance.

Download .excalidraw source Edit on excalidraw.com

Kafka topic fanning out to three independent consumer groups (inventory, notification, and analytics), each receiving all messages
Figure 4.2: Publish-subscribe via multiple consumer groups: each group receives every message independently. Adding analytics-service requires no changes to the publisher or existing consumers.

Download .excalidraw source Edit on excalidraw.com

Pulsar topic with three subscriptions: inventory (Shared with two consumers), notification (Exclusive), and analytics (Exclusive)
Figure 4.3: Pulsar subscriptions: each subscription receives every message independently. The Shared subscription distributes work across multiple consumers; Exclusive subscriptions have one active consumer each.

Download .excalidraw source Edit on excalidraw.com

Dead Letter Channel and Guaranteed Delivery flow
Figure 5.1: Guaranteed Delivery with Dead Letter Channel as the fallback for exhausted retries.

Download .excalidraw source Edit on excalidraw.com

Messaging Bridge connecting Kafka to Pulsar
Figure 6.1: A Camel Messaging Bridge forwards events from Kafka to Pulsar for cross-system integration.

Download .excalidraw source Edit on excalidraw.com

Command, Event, and Document message types
Figure 7.1: The three message types and their channel/consumer affinities.

Download .excalidraw source Edit on excalidraw.com

Request-Reply pattern with Correlation Identifier
Figure 8.1: Request-Reply using separate channels and a Correlation Identifier to match replies.

Download .excalidraw source Edit on excalidraw.com

Content-Based Router, Splitter, and Recipient List
Figure 9.1: Three fundamental routing patterns: route by content, split into parts, fan out to a dynamic list.

Download .excalidraw source Edit on excalidraw.com

Scatter-Gather pattern
Figure 10.1: Scatter-Gather fans out to multiple recipients and aggregates their replies.

Download .excalidraw source Edit on excalidraw.com

Wire Tap pattern
Figure 11.1: Wire Tap sends a copy of the message to a monitoring channel without affecting the main flow.

Download .excalidraw source Edit on excalidraw.com

Message transformation pipeline
Figure 12.1: A transformation pipeline: translate, enrich from external data, filter out PII, produce canonical output.

Download .excalidraw source Edit on excalidraw.com

Aggregator pattern
Figure 13.1: The Aggregator collects correlated messages and emits a single combined result.

Download .excalidraw source Edit on excalidraw.com

Competing Consumers and Event-Driven Consumer
Figure 14.1: Competing Consumers scale horizontally; Event-Driven Consumers react to message arrival.

Download .excalidraw source Edit on excalidraw.com

Two application instances each with two consumer threads, distributing 12 Kafka partitions evenly: 3 partitions per thread
Figure 14.1: Competing consumer scaling: 2 instances × 2 threads = 4 consumers, each assigned 3 of 12 partitions.

Download .excalidraw source Edit on excalidraw.com

Outbox Pattern for transactional messaging
Figure 15.1: The Outbox pattern ensures atomic writes to the database and eventual publication to Kafka.

Download .excalidraw source Edit on excalidraw.com

Messaging Gateway pattern
Figure 16.1: Messaging Gateway hides the messaging system from application code

Download .excalidraw source Edit on excalidraw.com

Control Bus for route management
Figure 17.1: The Control Bus manages routes at runtime and exports metrics to observability tools.

Download .excalidraw source Edit on excalidraw.com

Test Message and Detour patterns
Figure 18.1: Test Message injection and Detour toggle

Download .excalidraw source Edit on excalidraw.com

Kafka cluster architecture
Figure K.1: Kafka cluster with KRaft, partitions, and consumer groups

Download .excalidraw source Edit on excalidraw.com

Three rebalancing scenarios: initial 2-consumer assignment, after Consumer C joins (3-way split), and after Consumer B crashes (2-way redistribution)
Figure B.1: Consumer group rebalancing: partitions are redistributed when consumers join or leave the group.

Download .excalidraw source Edit on excalidraw.com

Pulsar cluster architecture
Figure L.1: Pulsar cluster with stateless brokers and BookKeeper storage

Download .excalidraw source Edit on excalidraw.com

Redis four integration roles: caching, idempotent store, pub/sub, and distributed locking
Figure D.1: Redis serves four distinct roles in integration: cache-aside enrichment, idempotent message deduplication, pub/sub notifications, and distributed locking.

Download .excalidraw source Edit on excalidraw.com

JBang to Quarkus promotion workflow
Figure N.1: From JBang prototype to native Quarkus binary

Download .excalidraw source Edit on excalidraw.com

Drools rule-based content router: Kafka consumer to rule engine to routing destinations
Figure F.1: A Drools Rule Unit evaluates orders against DRL rules and decision tables, setting a routing decision that Camel's toD() uses to dispatch to the correct handler.

Download .excalidraw source Edit on excalidraw.com

Quarkus Flow order fulfillment workflow with state transitions and Camel integration
Figure G.1: The order fulfillment workflow as a Serverless Workflow state machine: operation states call CDI beans that invoke Camel routes for external system integration.

Download .excalidraw source Edit on excalidraw.com

flagd architecture
Figure Q.1: flagd evaluation with OpenFeature SDK

Download .excalidraw source Edit on excalidraw.com

LGTM observability stack: Camel services to OTel Collector to Loki, Tempo, Mimir, and Grafana
Figure I.1: The LGTM observability pipeline: Camel services emit traces, metrics, and logs via OpenTelemetry to the OTel Collector, which fans out to Loki, Tempo, and Mimir for Grafana visualization.

Download .excalidraw source Edit on excalidraw.com

Distributed trace showing spans across order-service and inventory-service, linked via Kafka header propagation
Figure I.1: Distributed trace: the produce span in order-service and the consume span in inventory-service are linked under the same trace ID via Kafka header propagation.

Download .excalidraw source Edit on excalidraw.com

Loan Broker Scatter-Gather architecture
Figure J.1: The Loan Broker: gateway, enricher, recipient list, bank services, and aggregator.

Download .excalidraw source Edit on excalidraw.com

Bond Trading market data distribution
Figure K.1: Bond Trading: multiple feeds normalized, filtered per desk, traded, and audited.

Download .excalidraw source Edit on excalidraw.com

Platform threads vs virtual threads: 1:1 OS mapping vs M:N scheduling with carrier pool
Figure M.1: Platform threads map 1:1 to OS threads; virtual threads share a small carrier pool and park on I/O

Download .excalidraw source Edit on excalidraw.com

Kafka consumer lifecycle showing fetch, poll, and commit operations between broker and consumer
Figure N.1: The consumer lifecycle: fetch batches from the broker, poll and process records, then commit offsets. Each step has configuration knobs that trade throughput against latency and safety.

Download .excalidraw source Edit on excalidraw.com

Kafka producer pipeline showing buffering, batching, compression, and broker acknowledgment
Figure O.1: The producer pipeline: records are buffered in the RecordAccumulator, batched by partition, optionally compressed, then sent to the broker. The broker acknowledgment flows back through a callback to the application.

Download .excalidraw source Edit on excalidraw.com

Comparison of traditional consumer groups with partition-bound assignment versus share groups with round-robin distribution
Figure P.1: Consumer groups (left) assign each partition to exactly one consumer; Consumer D is idle. Share groups (right) distribute messages round-robin across all consumers regardless of partition count.

Download .excalidraw source Edit on excalidraw.com

Data pipeline showing PostgreSQL flowing through Debezium source connector, Kafka, Camel route processing, and JDBC sink connector to analytics database
Figure R.1: A shipping domain pipeline: Debezium captures CDC events from PostgreSQL, Camel routes apply EIP logic (validate, enrich, route), and a JDBC sink connector writes processed orders to the analytics database. Each component manages its own offsets.

Download .excalidraw source Edit on excalidraw.com

Testing pyramid with three tiers: unit tests at the base, integration tests in the middle, Newman at the top
Figure S.1: The testing pyramid for Camel Quarkus: unit tests are fast and many, integration tests verify real infrastructure, Newman tests validate external API contracts.

Download .excalidraw source Edit on excalidraw.com

minikube cluster with Camel application pods, Strimzi Kafka, and Redis
Figure T.1: Kubernetes deployment architecture: the Camel application consumes orders from Kafka, enriches via Redis, and publishes to an enriched orders topic.

Download .excalidraw source Edit on excalidraw.com

Camel CLI prototype-to-production workflow
Figure U.1: The Camel CLI lifecycle: prototype with camel run, inspect with camel trace, export to a production Maven project.

Download .excalidraw source Edit on excalidraw.com

Camel TUI dashboard layout
Figure V.1: The Camel TUI dashboard layout: tab bar, main content panel, and status bar.

Download .excalidraw source Edit on excalidraw.com

Citrus test execution flow
Figure W.1: Citrus test lifecycle: start infrastructure via Testcontainers, launch the Camel route, send test messages, and verify results on output topics.

Download .excalidraw source Edit on excalidraw.com

Camel AI/MCP architecture
Figure X.1: Camel AI integration architecture: routes produce to LangChain4j agents, which call back to Camel route tools and external MCP servers.

Download .excalidraw source Edit on excalidraw.com

OpenShift Local project eip: a binary S2I build produces the eip-k8s-deploy image, an edge-TLS Route fronts the Camel application, which talks to AMQ Streams Kafka and Redis; KEDA and OpenTelemetry are opt-in
Figure Z.1: The Appendix T pipeline on OpenShift Local: Maven packages on the host, the cluster builds and stores the image, a Route terminates TLS, and the operator-managed Kafka and Redis run in the same project.

Download .excalidraw source Edit on excalidraw.com