A financial services organization is designing a real-time event processing architecture using Google Cloud. The architecture continuously ingests transaction streams from Pub/Sub, transforms and enriches the data using Cloud Dataflow, and writes the output to an Apache Kafka cluster for downstream consumer applications. The system must meet the following requirements: Downstream Kafka consumers require strict deduplication and exactly-once processing semantics. Broker outages or brief network partitions must not trigger premature transaction timeouts that result in duplicate records. Future updates to the Dataflow pipeline business logic must be deployed without losing exactly-once delivery guarantees. How should the architect configure the Dataflow streaming pipeline and Kafka integration to meet these requirements?

Configure the Dataflow `KafkaIO` write transform with `withEOS()`, increase Kafka's `transaction.max.timeout.ms` to align near the topic retention time, and deploy pipeline modifications using pipeline updates instead of pipeline drains.: ### What this solution is This architecture configures **Cloud Dataflow's** `KafkaIO` sink connector for **Exactly-Once Semantics (EOS)**, optimizes Kafka transaction timeouts, and enforces non-disruptive pipeline deployment practices for streaming data movement. ### How it meets the requirements - **Strict Deduplication / Exactly-Once:** Enabling `withEOS()` on the Beam `KafkaIO` transform forces Dataflow to use transactional writes to Kafka, ensuring records are written exactly once downstream. - **Resilience to Broker Outages:** Aligning `transaction.max.timeout.ms` with Kafka topic retention gives ongoing transactions sufficient time to commit after transient network issues or broker reboots, preventing aborted transactions that lead to retried duplicates. - **Safe Deployments:** In-flight pipeline updates (`gcloud dataflow jobs run ... --update`) preserve the execution graph and state without triggering a drain phase, maintaining exactly-once semantics. ### Key advantages and capabilities - **Transactional guarantees:** Eliminates downstream data corruption and reconciliation errors caused by duplicate stream processing. - **Robust fault tolerance:** Mitigates the impact of transient connectivity loss between Google Cloud and external Kafka brokers. - **Zero-downtime evolution:** Allows seamless updates to Apache Beam transformation logic while keeping streaming state intact. - **Managed scaling:** Leverages Dataflow's auto-scaling workers to balance stream processing demands against low-latency targets. ### Why this is optimal Default Kafka write connectors only offer at-least-once delivery. Draining a pipeline bypasses commit acknowledgments for late/in-flight offsets, breaking EOS. Combining `withEOS()`, tuned transaction timeouts, and in-place pipeline updates ensures unbroken end-to-end exactly-once stream processing.

StudyCerts

Dataflow Kafka Streaming Exactly Once Delivery | Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam! | StudyCerts

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Dataflow Kafka Streaming Exactly Once Delivery

Section: Movement of data

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A financial services organization is designing a real-time event processing architecture using Google Cloud. The architecture continuously ingests transaction streams from Pub/Sub, transforms and enriches the data using Cloud Dataflow, and writes the output to an Apache Kafka cluster for downstream consumer applications.

The system must meet the following requirements:

Downstream Kafka consumers require strict deduplication and exactly-once processing semantics.
Broker outages or brief network partitions must not trigger premature transaction timeouts that result in duplicate records.
Future updates to the Dataflow pipeline business logic must be deployed without losing exactly-once delivery guarantees.

How should the architect configure the Dataflow streaming pipeline and Kafka integration to meet these requirements?

Configure the Dataflow KafkaIO write transform with withEOS(), increase Kafka's transaction.max.timeout.ms to align near the topic retention time, and deploy pipeline modifications using pipeline updates instead of pipeline drains.

Use the standard KafkaIO write transform without withEOS(), set transactional.id.expiration.ms to 0, and cancel the running Dataflow job before submitting a new job version.

Configure the Dataflow KafkaIO write transform with withEOS(), configure pipeline drain operations during deployments, and rely on default Kafka broker client timeout settings.

Configure the Dataflow pipeline using at-least-once streaming mode, reduce Kafka's transaction.max.timeout.ms to 1,000 milliseconds, and drain the Dataflow pipeline whenever pipeline updates are deployed.

Professional Cloud Architect

Dataflow Kafka Streaming Exactly Once Delivery

Related questions