Chris Cranford
Principal Software Engineer, IBM - Debezium maintainer
Charlotte, North Carolina, United States
Actions
Chris Cranford is a Principal Software Engineer at IBM, previously at Red Hat, and one of the longest-serving maintainers of Debezium, the open-source change data capture project, where he serves on the extended governance committee. He is the primary maintainer of the Oracle connector and helps set the project's technical direction. He started Debezium's JDBC sink connector and its upcoming Elasticsearch sink, and contributed the Debezium Quarkus extensions for the outbox pattern and for running connectors. Chris also worked on Hibernate ORM through its 4, 5, and 6 releases. Off the clock, he's usually buried in a book or losing a tug-of-war to his dog, who has no respect for transaction boundaries.
Links
Area of Expertise
Topics
Inside a Change Data Capture Connector: Memory, Batching, and the JVM
"Just read the transaction log" is the standard advice for change data capture, and it hides a multi-year engineering problem. The log exists for crash recovery, not for consumers: concurrent transactions are interleaved, rollbacks appear after the fact, and the position you can safely resume from is not the position you last read.
This talk follows one transaction from COMMIT to an event stream, drawn from years of maintaining Debezium's Oracle connector, with the PostgreSQL and MySQL equivalents throughout. Most of the hard parts turn out to be JVM problems. We'll cover:
- Buffering until commit: heap, off-heap, and disk-backed caches, and GC pressure from long transactions.
- Mining the log in windows over JDBC without dropping or duplicating events.
- What an offset really is, and why a naive restart replays or skips.
- Schema changes that land mid-stream.
- Long-open transactions, log retention, and the JMX metrics that warn you first.
No DBA knowledge required. You'll leave knowing why CDC tools behave the way they do, and what to ask before trusting one with production data.
Target audience: developers and architects who use change data capture or are evaluating it and want to understand what the tool is actually doing between a commit and an event. Intermediate. No Oracle or DBA knowledge required; every section is explained from first principles and mapped to PostgreSQL and MySQL.
Format and duration: regular 55-minute session, about 45 minutes of talk with 10 minutes for questions.
Technical requirements: slides, plus a short demo showing a transaction moving through the connector. Nothing depends on conference Wi-Fi. Projector with HDMI.
First public delivery: yes. This is a new talk and has not been given elsewhere.
Related prior talks: Change Data Streaming Patterns in Distributed Systems, Devnexus 2023. No overlap: that talk covered patterns for consumers of change events; this one covers how the events are produced.
Additional information: I maintain the Oracle connector for Debezium, an open-source project under the Commonhaus Foundation, so the failure modes described are first-hand. Oracle is the worked example because it is where every hard problem appears at once, not as a product focus; the talk is vendor-neutral. It is placed in Java & the JVM Ecosystem because the engineering problems are JVM problems: memory management for large in-flight state, off-heap and disk-backed caches, batching and streaming over JDBC, and JMX observability. It also speaks to the committee's question of which established engineering principles matter most now: bounded memory, safe restarts, and honest offsets keep any downstream consumer, including an AI pipeline, from silently missing data. It would also fit System Design.
When the Consumer Is an Agent: Change Streams for Nondeterministic Systems
Teams are wiring AI agents to their databases the way they once wired microservices: a row changes, an event fires, and an agent decides what to do. But change streams deliver at-least-once, which is harmless only when the consumer is deterministic. If you replay an event to an agent, it may take a different action and charge you twice for the model call. When it writes back, its own change arrives in the stream and triggers it again.
This session presents architectural patterns for agents that consume change streams, with Debezium as the running example:
- Replays: recording the agent's decision instead of re-deriving it, because idempotency keys aren't enough.
- Feedback loops: attributing writes so an agent doesn't trigger itself.
- Transaction boundaries: never acting on half a transaction.
- The outbox pattern: committing an action and its decision together.
- Recovery: staleness limits and when a replayed event goes to a human.
You'll leave with patterns for putting a nondeterministic consumer on a change stream, and the questions to ask before any agent reacts to production data.
Target audience: developers and architects building agents that react to changes in operational data, and the platform teams who will run them. Intermediate. Familiarity with event-driven systems helps; no change data capture or agent framework experience is needed.
Format and duration: regular 55-minute session, about 45 minutes of talk with 10 minutes for questions.
Technical requirements: slides only, no live demo. Projector with HDMI.
First public delivery: yes. This is a new talk written for Devnexus 2027.
Related prior talks: Change Data Streaming Patterns in Distributed Systems, Devnexus 2023. That talk covered consumer patterns for conventional, deterministic services. This one asks which of those patterns fail when the consumer is an agent, and what replaces them. The overlap is limited to a brief recap of delivery semantics.
Additional information: the patterns are vendor-neutral; Debezium is the running example because I maintain it, and the same issues apply to any change stream feeding an agent. I have built both ends of these pipelines, the Oracle source connector and the JDBC sink connector, so the delivery guarantees discussed are ones I have implemented rather than observed. This session complements my Production AI Engineering submission, which covers the read path (keeping a retrieval index current). This one covers agents that react to changes and write back, where the problems are replay, feedback loops, and attribution rather than freshness. The track notes that AI does not remove the need for sound architecture and, in many cases, makes it more important; this talk is a concrete example of that. It is placed in System Design because it covers architectural patterns for systems with a probabilistic component in the loop, and because established principles (idempotency, transactional handoff, auditability) matter more once that component is present.
Your Vector Store Is Already Out of Date
When a language model answers from your own data, it isn't reading your database. It's reading a vector index built from it, and that index is only as current as its last build. Refresh it nightly, and the model answers confidently from yesterday's prices, inventory, or account status, and every refresh re-embeds everything to catch the one percent that changed.
Change data capture closes that gap. We'll walk through a working pipeline, all in Java: PostgreSQL, Debezium Server computing embeddings in flight and writing them straight into Milvus with no Kafka in between, and a Quarkus service using LangChain4j answering questions over data that changed seconds earlier. Along the way:
- Deletes and updates in a vector index, and why tombstones matter.
- Chunking rows that don't look like documents.
- Where embedding should run: pipeline, sink, or application.
- Rebuilding the index without stopping the stream.
- Measuring lag from commit to vector store, and catching stale answers before users do.
- Offsets, restarts, and what happens when the vector store is down.
No CDC background needed. You'll leave with a design to keep retrieval in step with the system of record, plus a checklist to run it.
Target audience: developers who have shipped or are about to ship a retrieval or RAG feature against a live database, and the platform and data engineers who have to keep it accurate afterward. Intermediate. Basic familiarity with embeddings and vector search is assumed. No change data capture experience is needed; I cover it from scratch early in the talk.
Format and duration: regular 55-minute session, about 45 minutes of talk and demo with 10 minutes for questions.
Demo and technical requirements: the demo is a pre-built pipeline running on my laptop in containers: PostgreSQL, Debezium Server with the embeddings transformation writing directly to Milvus (no Kafka), and a Quarkus service using LangChain4j. Embeddings and the answering model run locally, so the demo does not depend on conference Wi-Fi or a hosted API. I need a projector with HDMI and a power outlet. The demo shows a finished pipeline with one change made live so the audience sees the freshness difference; there is no on-stage building.
First public delivery: yes. This is a new talk written for Devnexus 2027.
Related prior talks: none on this topic. My previous Devnexus session (2023) was on change data streaming patterns in distributed systems and did not cover AI or vector workloads.
Additional information: everything shown is open source and vendor-neutral. Debezium is a Commonhaus Foundation project. I started Debezium's JDBC sink connector and am building its Elasticsearch sink, so the sink-side problems in this talk (upserts, deletes, and tombstones landing in a target that was not designed for a change stream) are ones I have solved in code rather than observed. The pipeline deliberately runs without Kafka to show that CDC into a vector store is a single-process concern; the same connector runs under Kafka Connect for teams that already have it. The talk fits Production AI Engineering because it is about what happens after the RAG prototype works, and it speaks to the track's call for systems that are observable and economically sustainable: the pipeline re-embeds only what changed rather than the whole corpus, and exposes end-to-end lag as a metric you can alert on; it would also fit Building AI-Native Applications if the committee prefers.
Chris Cranford
Principal Software Engineer, IBM - Debezium maintainer
Charlotte, North Carolina, United States
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top