Optimizing Cloud Native Java: Quarkus Where the Memory Limit Is Real

### Abstract

The JVM was designed for a long-lived process on a dedicated machine with all the memory it could see. A container is the opposite of that in every respect: short-lived, sharply constrained, and scheduled by something that will kill it without ceremony the moment it crosses its memory limit. The defaults were tuned for the first world and your service runs in the second.

This talk is about closing that gap for Quarkus workloads. We will look at what the JVM actually perceives from inside a container, where its ergonomics guess wrong, and what you can do about startup time, resident memory, and throughput — including the honest accounting of which of those three you are giving up when you improve the other two.

**What you'll learn:**

- Read what the JVM sees inside a container — cgroup limits, CPU quota versus shares, and the specific places ergonomics draw the wrong conclusion
- Cut startup time with AppCDS and the AOT cache, and judge when native compilation earns its build-time cost
- Size heap against non-heap correctly, so the OOM killer stops being an unplanned part of your architecture
- Measure the tradeoff triangle — startup, throughput, footprint — and pick the two that matter for your workload
- Tune differently for the scaling pattern you actually have: steady long-running services versus scale-to-zero

**Demos:** one service built five ways — default JVM, tuned JVM, AppCDS, AOT cache, native — measured for startup, resident memory, and throughput under load; a pod reproducibly OOM-killed and then fixed; garbage collector choice changing behaviour under a tight CPU quota.

**Key Takeaways:**
Attendees leave able to explain where their Java service's memory actually goes, why it starts as slowly as it does, and which lever to pull for their particular deployment shape. The numbers from the demos are less important than the method for producing your own.

This is not a benchmark shootout, and it will not end with a recommendation to use native mode for everything. It is about knowing precisely which number you are trading away.

### Level of Expertise

Intermediate — attendees should write Java and have deployed something to Kubernetes or OpenShift. No prior JVM tuning experience assumed.

### Target Audience

Java developers, architects, and platform engineers running JVM workloads on Kubernetes or OpenShift — particularly anyone who has been handed a memory limit by a platform team and asked to make it fit.

Requirements:

Laptop
Browser
Github account
Basic Java Skills

From First Route to Saga: A Full-Day Camel Integration Build

### Abstract

By 3pm on a real on-call shift, "just add a retry" has already been tried, has already made things worse, and someone is now asking why the same booking got created twice. This workshop puts you inside that problem on purpose, for a full day. You'll stand up a shipping-domain integration pipeline — bookings arriving from two partners, in two formats, over two transports — take it from a single route to a hardened pipeline, then spend the afternoon injecting the failures that force you to reach for idempotent consumer, dead letter channel, and saga for real reasons instead of as an exercise. This isn't a lecture with slides between patterns. It's a full day of writing Camel routes on your chosen runtime, breaking them on purpose, and fixing them because the pipeline demands it.

**What we'll do:**

- Stand up a Camel route on your chosen runtime — Quarkus or Spring Boot — from scratch and grow it into a content-based router
- Split an inbound batch, enrich each element against a reference service, and aggregate the results back together
- Make the pipeline idempotent so a partner's duplicate delivery stops corrupting downstream state
- Add a dead letter channel and retry with backoff, and watch a poison message and a flaky call stop taking the route down with them
- Implement a saga that compensates a booking when a downstream service fails halfway through
- Optionally, build out a three-tier test suite and an AI-driven classification layer on top of the same routes

**Workshop Structure:**

- Setup & scenario orientation (30 min)
- Foundations: first routes + content-based router (45 min)
- Splitter, content enricher, aggregator over a booking batch (60 min)
- Resilience: idempotent consumer, dead letter channel, retry with backoff (60 min)
- Saga: compensating a partially completed booking across services (45 min)
- Optional module — Testing pyramid: MockEndpoint/AdviceWith (unit), Quarkus Dev Services + REST Assured (integration), Newman (API), Citrus end-to-end vs real infra via Testcontainers (45 min)
- Optional module — AI integration: LangChain4j classification in a content-based router, ai-tool tool-calling, MCP, Wanaku (Quarkus + Ollama qwen2.5:3b) (45 min)
- Debrief & pattern decision map (30 min)
- Breaks: morning 15 min + lunch 45 min + afternoon 15 min

**Technical Details:**
Participants work in Java with the Camel extensions on either Quarkus or Spring Boot — chosen at registration, with identical exercises in both. A `docker compose` stack provides Kafka, Postgres, an FTP endpoint, and a Grafana LGTM stack. Starter code is in the public repo `patterncatalyst/enterprise-integration-patterns-with-camel`; install requirements are Docker, a JDK, and Git; each exercise has a completed branch to fall back on.

### Level of Expertise

Intermediate — comfortable writing Java; no Camel or messaging background required.

### Target Audience

Developers and architects who build or maintain integrations, especially teams about to standardize on Camel as their integration runtime — on either Quarkus or Spring Boot.

Requirements:

Laptop
Browser
Github account
Basic Java Skills

Eight Patterns, One JVM: Enterprise Integration on Camel and Quarkus

### Abstract

Ask five engineers on your team what happens when a partner sends a malformed payload, or a downstream call fails halfway through a multi-step booking, and you'll get five different answers — a null check here, a manual retry there, a Slack thread instead of a design. Nobody wrote these down as patterns; they just accreted as fixes. Hohpe and Woolf named eight of them decades ago, and Camel on Quarkus turns each one into a route you can point at and say "that one, right there."

This talk works through the eight integration patterns that show up in nearly every service that talks to more than one other system — and builds each one live, as a Java route running on Quarkus. The same routes run unmodified on Spring Boot too; this talk builds and demos on Quarkus, which stays the lead runtime throughout.

**What you'll learn:**

- Route inbound traffic by shape and content instead of a stack of if-statements, using a content-based router
- Break a batch into individually processable pieces with a splitter, pull in reference data with a content enricher, and reassemble the result with an aggregator
- Stop a partner's duplicate delivery from corrupting downstream state with an idempotent consumer
- Contain a bad message with a dead letter channel and recover a flaky downstream call with retry with backoff — without either one taking the route down
- Coordinate a multi-service booking with a saga instead of reaching for two-phase commit

**Demos:** a content-based router splitting a mixed booking feed; a splitter/content-enricher/aggregator trio processing a batch end to end; an idempotent consumer absorbing duplicate delivery; a dead letter channel and retry with backoff catching a malformed booking without wedging the route; a saga compensating a partially completed booking across services.

**Key Takeaways:**
Attendees leave with eight patterns mapped directly onto working Camel-on-Quarkus code, and with the instinct to recognize, mid-incident, which one the failure in front of them is asking for. Each pattern is shown paired with the specific failure mode it exists to contain.

This is not about Camel's full component catalog or a survey of every runtime it can target. It's about the eight patterns that carry most Quarkus integration code, built once, correctly, so you stop reinventing them under pressure.

**Also in the repo (take-home appendix, shown only if time allows):** an AI appendix — Camel LangChain4j Chat classification inside a content-based router, `ai-tool` + LangChain4j agent tool-calling, MCP integration, and Wanaku exposing Camel routes as AI tools (Quarkus + Ollama qwen2.5:3b) — plus a three-tier testing setup.

### Level of Expertise

Intermediate — comfortable with Java; no Camel experience assumed.

### Target Audience

Integration developers, architects, and Java engineers building or maintaining Quarkus services that talk to more than one other system.

Requirements:

Laptop
Browser
Github account
Basic Java skills

Building an Integration Pipeline: Patterns You can Run

### Abstract

Reading about integration patterns is easy. Knowing which one to reach for when a partner's feed arrives malformed at 3am is a different skill, and it is only learned by building something and then breaking it.

In this workshop you will build a working integration pipeline for a shipping domain. Bookings arrive from two partners in two formats over two transports. You will normalize them, split a batch into individual bookings, enrich each one against a reference service, route by content, and publish downstream — and then we will start injecting failures. Duplicate deliveries, a poison message, a downstream service that goes away mid-transaction. Each failure introduces the pattern that handles it.

**What we'll do:**

- Build a Camel route from scratch and grow it into a content-based router
- Split an inbound batch, enrich each element, and aggregate the results back together
- Make the pipeline idempotent so a partner's duplicate delivery stops corrupting downstream state
- Add a dead letter channel and watch a poison message stop taking the route down with it
- Implement a saga that compensates a booking when a downstream service fails halfway
- Trace a single message across the whole pipeline in Grafana

**Workshop Structure:**

- Setup and orientation to the scenario (15 min)
- First routes: from, to, and content-based routing (20 min)
- Splitter, content enricher, and aggregator over a booking batch (30 min)
- Injecting failure: idempotent consumer, dead letter channel, retry with backoff (25 min)
- Saga: compensating a partially completed booking across two services (20 min)
- Debrief and building the pattern decision map (10 min)

**Technical Details:**
Participants work singly or in pairs in Java with Quarkus and the Camel extensions. A `podman compose` stack provides everything else — Kafka, Postgres, an FTP endpoint, and a Grafana LGTM stack for tracing — so nothing needs installing beyond Podman, a JDK, and Git. Starter code is in a public repository with setup instructions and a working baseline, so no one spends the first half hour fighting a build. Each exercise has a completed branch to fall back on.

### Level of Expertise

Intermediate — comfortable writing Java. No Camel or messaging background required; the patterns are introduced as the failures that motivate them appear.

### Target Audience

Developers and architects who build or maintain integrations. Especially suited to teams about to replace a hand-rolled integration layer, and to anyone who has been told to "just add a retry."

Requirements:

Laptop
Browser
Github account
Basic Java skills

Enterprise Integration Patterns with Camel and Quarkus

## Sixty-Five Patterns and One Runtime: Enterprise Integration with Apache Camel

### Abstract

Every integration starts as a single HTTP call. Then a retry gets bolted on, someone adds a queue, a nightly poller appears to catch what the queue dropped, and eighteen months later you are operating a distributed system nobody designed. The worst part is that each of those decisions was locally reasonable.

These problems were catalogued and named more than twenty years ago. Hohpe and Woolf's sixty-five integration patterns describe the shapes your integration is already taking, and Apache Camel implements them directly — so the pattern you draw on a whiteboard is close to the code you deploy. This talk connects the two: the vocabulary that lets a team reason about integration, and the runtime that makes the pattern executable.

**What you'll learn:**

- Map the integration problems you already have onto named patterns, so design discussions stop starting from zero
- Build routes with Camel's DSL for the patterns that carry most systems — content-based router, splitter, aggregator, content enricher
- Make integrations survive reality with dead letter channels, idempotent consumers, and retry with backoff
- Coordinate long-running distributed work using the Saga pattern instead of reaching for two-phase commit
- Run Camel on Quarkus in containers, and understand what that does to startup, memory, and native compilation

**Demos:** a content-based router splitting a mixed inbound feed; a splitter/aggregator processing a batch and reassembling the result; an idempotent consumer absorbing duplicate delivery; a poison message landing in a dead letter channel rather than wedging the route; a saga compensating a partially completed booking.

**Key Takeaways:**
Attendees leave with a working vocabulary and running code for the patterns that appear in nearly every integration. More importantly, they leave able to recognize which pattern a given problem calls for — and which failure mode that pattern introduces in exchange, because every one of them trades a problem for a different problem.

This is not a tour of Camel's three-hundred-component list. It is about recognizing that your integration problem already has a name, a diagram, and a well-understood failure mode.

### Level of Expertise

Intermediate — attendees should be comfortable with Java and have worked on at least one system that talks to another system. No prior Camel experience assumed.

### Target Audience

Integration developers, solution architects, and Java engineers who have inherited integration code they did not write. Also useful for architects standardizing how their teams describe integration designs.

Everything will be done in a browser.

Requirements:

Laptop
Browser
Github account

Making the Invisible Visible: Domain-Driven Observability in Distributed Systems

When distributed systems fail, they fail in the language of infrastructure—timeouts, connection pools, and circuit breakers. But when stakeholders ask "what went wrong?", they speak in the language of the domain—failed orders, delayed shipments, or missed payments. This gap between technical observability and business understanding creates a critical blind spot.

This talk demonstrates how Domain-Driven Design principles transform observability from an infrastructure concern into a strategic business capability. You'll learn practical techniques for designing observable bounded contexts, modeling domain events as first-class observability signals, and building monitoring that speaks the ubiquitous language. We will be doing this work using a Quarkus ecosystem.

**What you'll learn:**

- How to apply DDD tactical patterns (aggregates, domain events, bounded contexts) to design inherently observable systems in a Quarkus environment
- Techniques for correlating technical metrics with business outcomes using domain-driven correlation IDs and causation chains
- Strategies for making implicit domain knowledge explicit through structured logging and domain-specific metrics
- Real-world patterns for debugging distributed workflows by following the domain story rather than the technical stack trace
- How to bridge the gap between technical observability and business stakeholder understanding

**Key Takeaways:**
Attendees will leave with concrete patterns for implementing observability that serves both technical debugging and business understanding. You'll see how proper bounded context design naturally enables better tracing, how domain events become powerful audit trails, and how the ubiquitous language makes logs readable by domain experts, not just engineers.

This is not about specific monitoring tools—it's about applying DDD thinking to make your entire distributed system tell its own story in terms your business can understand.

### Level of Expertise

Intermediate - Attendees should have basic familiarity with distributed systems concepts and some exposure to DDD principles (bounded contexts, domain events, ubiquitous language).

### Target Audience

Software architects, technical leads, and senior developers working on distributed systems who want to bridge the gap between technical observability and business understanding. Also valuable for domain modelers seeking to understand the operational aspects of their designs.

Building Observable Domains - A Hands-on Journey using Quarkus

Observability in distributed systems is often treated as an afterthought—something we bolt on once the domain logic is "done." This hands-on session flips that approach by exploring how Domain-Driven Design and observability can evolve together, creating systems that are both well-modeled and deeply transparent.

In this practical workshop, you'll work through a realistic e-commerce scenario where a seemingly simple "checkout" operation spans multiple bounded contexts (Inventory, Payments, Shipping, Notifications). Together, we'll model these contexts, implement key domain events, and then progressively add observability that reflects the domain model—not just the technical infrastructure.

**What we'll do:**

- Model a multi-context business process using EventStorming techniques
- Design domain events that serve both business logic and observability
- Implement correlation strategies using domain-driven identifiers (not just trace IDs)
- Create structured logs that speak the ubiquitous language
- Build domain-specific metrics that answer business questions like "How many orders are stuck in payment verification?"
- Debug a distributed failure by following domain events across contexts

**Workshop Structure:**

- Introduction and setup (15 min)
- Collaborative domain modeling session (30 min)
- Hands-on coding: Implementing observable domain events (45 min)
- Debugging exercise: Following a cross-context failure (20 min)
- Group reflection and discussion (15 min)

**Technical Details:**
Participants will work singly or in pairs using provided starter code in either C#, Java, or Python (specify your preference when registering). The exercises focus on domain modeling and event design rather than specific observability tools, though we'll use simple logging frameworks and in-memory event stores. Basic Git and Quarkus along with a browser are all that's required.

All code and exercises will be shared in a GitHub repository with clear setup instructions. No prior expertise in observability tools required—just curiosity about connecting domain modeling with operational concerns.

### Level of Expertise

Intermediate - Participants should be comfortable writing code in at least one of the supported languages and have basic understanding of DDD concepts (bounded contexts, domain events). Prior experience with distributed systems helpful but not required.

### Target Audience

Developers and architects who want practical experience applying DDD principles to observability challenges. Perfect for teams about to embark on distributed system projects or those looking to improve their existing observability strategy through better domain modeling.