Oracle GoldenGate has long been the strategic platform for real-time data replication, enabling high availability, migrations, disaster recovery, and zero-downtime maintenance for mission-critical Oracle databases.
Today, many organizations have already or are modernizing their application architectures by adopting Apache Kafka as a central event streaming platform. Microservices, real-time analytics, artificial intelligence, machine learning, and cloud-native applications increasingly rely on a continuous stream of operational data rather than scheduled batch integrations.
When these initiatives begin, a common architectural question arises: how should Oracle database changes be delivered to Kafka?
Many teams first consider deploying an additional CDC platform that independently mines Oracle redo logs and publishes events into Kafka. However, when Oracle GoldenGate is already capturing the required committed database changes, introducing another redo-mining platform may not provide additional value for the same use case.
If Oracle GoldenGate is already capturing the required committed changes, why introduce another CDC engine to mine the same redo?
This article discusses an alternative architecture that extends an existing Oracle GoldenGate deployment by adding Oracle GoldenGate for Distributed Applications and Analytics as an additional trail consumer that publishes change data into Apache Kafka.
Why Stream Oracle Data to Kafka?
Apache Kafka has become the industry standard for distributing operational data to multiple consumers in real time. Instead of each application reading directly from the operational database, database changes are published once and consumed by many downstream systems independently.
Event-Driven Applications
Modern applications communicate through events rather than direct database access. When a business transaction occurs, downstream services can react independently without tight coupling to the source database.
Real-Time Analytics
Streaming Oracle transactions into Kafka allows analytics platforms to receive operational data with low latency, enabling dashboards and reports to reflect current business activity.
Artificial Intelligence and Machine Learning
Publishing Oracle change data into Kafka enables AI pipelines and feature stores to consume current business information without querying production systems directly.
Data Platforms and Integration
Kafka is commonly used as the integration layer for delivering operational data to data lakes, cloud analytics platforms, and downstream integration services through consumers, stream processing, or connectors.
Customer Scenario
A customer already had Oracle GoldenGate deployed to replicate Oracle databases. A new business initiative required Oracle database changes to be published into Apache Kafka.
The initial proposal was to deploy a second CDC platform that would independently capture Oracle redo information and publish change events. Although technically feasible, this approach would introduce an additional redo-mining infrastructure alongside an existing Oracle GoldenGate deployment.
Since the existing Oracle GoldenGate Extract was already capturing the required committed database changes for the tables involved in the project, the architectural question became: can the existing GoldenGate capture infrastructure simply be extended to publish changes into Kafka?
Proposed Architecture
Rather than introducing another capture platform, the existing Oracle GoldenGate Extract and trail remain unchanged. A new Oracle GoldenGate for Distributed Applications and Analytics Replicat is added as an independent consumer of the existing compatible GoldenGate trail.
Oracle GoldenGate Extract continues capturing committed changes for the configured source tables and writing them to the existing GoldenGate trail. The Oracle GoldenGate for Distributed Applications and Analytics Replicat independently reads the compatible trail, invokes the Java Delivery module and Kafka Handler, formats change records as JSON, and publishes them into Apache Kafka topics.
The existing database replication path remains unchanged while Kafka becomes an additional delivery target.
Proof of Concept
To validate this architecture before customer implementation, a Proof of Concept (POC) was developed in the Oracle VCAP laboratory. The objective was to simulate the customer’s production architecture while leaving the existing Oracle GoldenGate capture configuration unchanged.
The test environment consisted of Oracle Database 19c, Oracle GoldenGate Microservices Architecture, the existing Oracle GoldenGate Extract, and the existing GoldenGate trail. On the delivery side, Oracle GoldenGate for for Distributed Applications and Analytics was used with Apache Kafka running on a separate server.
Although the customer architecture includes a dedicated GoldenGate Hub, the laboratory simulated this by installing Oracle GoldenGate for Distributed Applications and Analytics as a separate GoldenGate installation while maintaining complete separation from the existing GoldenGate MA deployment.
The POC validated successful processing of Oracle database changes into Kafka without requiring modifications to the Oracle Database, GoldenGate Extract configuration, or existing database replication path.
Production Considerations
While the POC demonstrated that the existing capture path can be reused, production deployments should also consider trail contents, key columns, before and after images, metadata requirements, capacity planning, Kafka security, topic design, message key strategy, trail retention, and operational recovery procedures.
These considerations help ensure that Kafka delivery integrates cleanly into an existing GoldenGate deployment without affecting operational stability.
Benefits of the Architecture
- Reuse existing Oracle GoldenGate investment: continue using Oracle GoldenGate as the single capture platform rather than introducing another redo mining solution.
- Preserve existing capture infrastructure: the current Extract and replication configuration continue operating without reconfiguration.
- Lower operational complexity: one capture platform supports multiple delivery targets.
- Faster adoption of event streaming: Kafka delivery can be introduced by adding a new Replicat instead of redesigning the existing replication architecture.
- Incremental modernization: organizations can adopt event-driven architectures while preserving existing Oracle GoldenGate deployments.
Acknowledgment
I’d like to thank my colleague Mohamed Khalifa for collaborating with me on this article. Many of the ideas, POC and architectural discussions presented here were developed by him, and his technical insights were invaluable throughout the writing process.
Conclusion
Organizations that already use Oracle GoldenGate for database replication often possess the CDC infrastructure needed to support modern event-driven architectures.
When the existing GoldenGate trail already contains the required changes, Oracle GoldenGate for Distributed Applications and Analytics or in current releases, Oracle GoldenGate for DAA can extend that capture infrastructure by publishing change data into Apache Kafka without introducing another redo-mining platform.
Rather than replacing an existing Oracle GoldenGate deployment, Kafka becomes another supported delivery target, enabling organizations to modernize their integration architecture while preserving existing investments and operational stability.