Develop With Oracle Transactional Event Queues

This article provides a quick tour of Oracle's Transactional Event Queues (TEQ) and so attempts to cover as much as possible at a high-level while giving quick, low-level, and code examples at the same time. There is quite a bit of material, and there are multiple workshops related to TEQ and its use in modern application development and microservices that can be found at the end of this piece.

This article corresponds to a 12-minute video that can be found here...

Oracle Transactional Event Queues (previously known as Advanced Queueing) has been around and widely used for decades (long before Kafka) and is well-harden technology. Here is a timeline to give an idea.

Timeline of Oracle AQ and transactional event queues.

Oracle Transactional Event Queues are built into the Oracle database and provide a high-performance, high-throughput, and reliable messaging platform for microservices, streaming events, and pub/sub along with all the inherent HA, security, etc. benefits of running in the Oracle database. It supports sharding and propagation and provides APIs in all common languages such as Java, Python, Javascript, C, .Net, and PL/SQL as well as Kafka and REST APIs. Again, all the aspects described, and a migration tool to move from AQ to TEQ, are shown briefly in the video referenced above.

TEQ integration within the SQLcl command-line tool allows powerful and convenient administration within the shell, and REST APIs for TEQ, provided by Oracle REST Data Services, allow a convenient way to connect and view various queue characteristics without issuing any code.  This also allows for creating simple user-friendly interfaces.

Monitoring of TEQ is provided by an Oracle database metrics exporter that is scraped to provide Prometheus metrics to Grafana for analysis, alerts, etc.

The event broker and event mesh architecture of TEQ provided a number of features including the ability to propagate messages even across regions, interoperate with Kafka brokers via Kafka Connector bridge, and even allow developers to program to the Kafka API while seamlessly using TEQ and the advantages it provides.

Finally, due to the fact that TEQ runs within the database, it has the very unique ability to conduct messaging and database operations within the same local transaction. This provides tremendous power and simplification for the developer, particularly in microservice environments where data integrity and transactional messaging guarantees are vital. I elaborate on this aspect in my blog Apache Kafka vs. Oracle Transactional Event Queues as Microservices Event Mesh.

I hope you get a better understanding of what TEQ has to offer after this quick tour.  

You can learn more by checking out these workshops that contain labs showing much of the functionality described:

Finally, as always, please feel free to contact me with any questions or comments you have, and thanks for reading.

 

 

 

 

Top