Confluent Apache Flink Certificate case studies
Confluent Apache Flink Certificate · Put your knowledge to work in context.
The Confluent Certified Developer for Apache Kafka (CCDAK) is one of the certifications Confluent offers to validate Apache Kafka expertise. Confluent describes it as designed for developers and solution architects who build applications with Apache Kafka, validating the essential knowledge needed to develop, deploy, and maintain robust, real-time streaming applications using Kafka's core APIs and platform capabilities. The Confluent Apache Flink Certificate case studies are 5 cases and about 3,442 words.
1One heartbeat partition freezes every event-time window
clickstream in Confluent Cloud has 16 partitions and carries roughly 45,000 events/s. A Flink SQL statement aggregates it into 1-minute tumbling windows and writes per-window counts to a dashboard topic.
682 words, about 3 min2Blue/green Flink jobs, transactional id fencing and doubled revenue
orders-enrich is a self-managed Flink 1.19 job on Kubernetes. It reads orders raw from Confluent Cloud and writes orders enriched through KafkaSink with DeliveryGuarantee.EXACTLY ONCE , transactional.id.prefix = "orders-sink" , 30 s checkpoints to S3, and all downstream consumers using read committed .
686 words, about 3 min3An unbounded regular join grows state to 1.4 TB and checkpoints never finish
orders enrich is a Flink SQL job on 8 task managers (64 GB each, 2 slots) joining orders (append-only, ~25k events/s, Confluent Cloud) with customers , a compacted changelog topic holding 200 million rows at roughly 1 KB each. The statement is a plain inner join on customer id , projecting segment and region onto each order.
727 words, about 4 min4A single 35% merchant defeats parallelism increases
merchant metrics computes 5-minute tumbling SUM(amount) and COUNT( ) grouped by merchant id from a 36-partition Confluent Cloud topic and writes the results to Kafka. Job parallelism is 24, checkpointing is every 5 minutes, and the source has a stable watermark.
663 words, about 3 min5Deduplication into upsert-kafka: retractions, tombstones and 3.1x message counts
orders raw receives order events from an at-least-once producer, so about 5% of order id s arrive twice with different updated at values. The pipeline deduplicates with ROW NUMBER() OVER (PARTITION BY order id ORDER BY updated at DESC) filtered to rn = 1 and initially wrote to a kafka sink topic orders dedup ; deployment failed immediately with an error stating that the Kafka sink does not support consuming update and delete changes.
684 words, about 3 min