Streaming: Markt

Stelle

eine offene Stelle, die das Qualitäts-Gate passiert hat und mindestens zwei Technologien nennt

Beobachteter Kandidat

ein Kandidat, dessen Stack diese Technologie enthält; ein Aggregat — kein einziger Datensatz verlässt den Perimeter

Matchbarer Kandidat

noch nicht gezählt

Fenster

Stellen, die zum Zeitpunkt der Erstellung des Snapshots offen waren

Pure Junior streaming openings are almost non-existent — it's not a first role; people come from Data Engineering, backend development or big data. The jump to Middle — confident work with Kafka (producers / consumers, partitioning), one stream-processing engine. Senior — designing streaming architectures, exactly-once, stateful processing on Flink, operating Kafka under load. Career flow: Data Engineer / backend → Streaming Middle → Senior → Streaming / Kafka Platform Lead / Data Platform Engineer / data architect.

Top 5: kafka, aws, python, flink, cloud. Streaming platforms: Apache Kafka (dominator — de-facto standard), Apache Pulsar, AWS Kinesis, Redpanda (Kafka-compatible, modern). Stream processing: Apache Flink (leader of complex stateful processing), Kafka Streams (lightweight processing inside Kafka), Spark Structured Streaming, ksqlDB (SQL over streams). Change Data Capture: Debezium (capture DB changes into a stream). Kafka ecosystem: Kafka Connect (source / sink integration), Schema Registry (Avro / Protobuf — message contracts), Confluent stack. Storage for streaming data: ClickHouse (real-time analytics — popular in CIS), sometimes Apache Druid, Pinot. Languages: predominantly JVM — Java and Scala (most engines), Python (PyFlink, clients). Concepts: distributed systems, partitioning and consumer groups, offsets, exactly-once / at-least-once semantics, backpressure, time windowing, watermarks, event sourcing, idempotency. Infrastructure: Docker / Kubernetes, monitoring (Prometheus + Grafana), CI/CD, SQL. Understanding of distributed systems and delivery guarantees is valued more highly than knowing a specific API.

Apache Kafka — the de-facto standard for event streaming: huge ecosystem (Connect, Streams, Schema Registry, Confluent), widespread, the most jobs and materials. Learn this first. Downsides — historically dependency on ZooKeeper (replaced by built-in KRaft in new versions), operation requires expertise. Apache Pulsar — architecturally interesting in places (storage/processing separation, built-in multi-tenancy, geo-replication), but ecosystem and adoption smaller than Kafka. AWS Kinesis — managed service in the AWS ecosystem: simpler to operate (no cluster admin), but vendor lock-in and less flexibility; sensible if your whole infrastructure is in AWS. Redpanda — Kafka-compatible platform (same API), written in C++, without JVM and ZooKeeper: simpler to operate, lower latency; modern alternative gaining popularity 2024–2026. Strategy 2026: learn Kafka — that's the market, the ecosystem and a transferable skill; Redpanda knowledge comes as a near-free bonus (same API). Pulsar / Kinesis — by company context. Message brokers like RabbitMQ are something else (reliable message delivery between services), don't confuse with a streaming platform for event streams.

Stream processing — processing data as it arrives, not in batches: filtering, aggregations in time windows, enrichment, joins of streams, pattern detection — in real time. Apache Flink — leader for complex stateful processing: true streaming model (processes event by event), powerful state and time handling (event time, watermarks), exactly-once, low latency; the choice for serious real-time tasks (fraud, complex on-the-fly analytics). Entry bar is higher. Kafka Streams — lightweight processing library right "inside" a Kafka application (not a separate cluster): simpler to operate, good for not-too-complex processing in a Kafka-centric architecture; Java / Scala only. Spark Structured Streaming — stream processing in the Spark ecosystem, works via micro-batch (small batches); convenient if the company already has Spark and wants batch and streaming in one stack, latency slightly higher. ksqlDB — stream processing in SQL, low entry bar for simple tasks. Strategy: Flink — the main skill for serious stream processing 2026; Kafka Streams — know as a simpler tool in the Kafka ecosystem; Spark Streaming — if the company is already on Spark. Choice depends on processing complexity and existing stack.

Event-driven architecture — a style of building systems where components communicate via events (facts "what happened") published to a stream (Kafka), rather than via direct synchronous calls. Services independently subscribe to the events they need. Pros — loose coupling, scalability, natural history of all changes. CDC (Change Data Capture) — a technique to capture changes from a database into an event stream: a tool (Debezium) reads the DB transaction log and publishes every change (insert / update / delete) to Kafka. Why — without loading the DB, get a stream of its changes to populate other systems (search indexes, caches, analytical stores, other services) in real time; a key way to "decouple" a monolithic DB and the event-driven world. Exactly-once semantics — one of the hardest topics in stream processing: a guarantee that every event will be processed exactly once, even under failures and restarts — not lost (at-least-once allows duplicates) and not duplicated. Critical, for example, for financial operations. Achieved through a combination of idempotency, Kafka transactions and checkpoints in the processing engine (Flink). Understanding these three concepts is the core of Streaming engineer expertise; interview questions and real architectural decisions are built around them.

Yes, 17% of Streaming jobs are remote or hybrid. Stream processing is engineering work with code, distributed systems and cloud / Kubernetes infrastructure, no physical presence required. Russian high-load employers (banks, marketplaces, telco) offer office, hybrid and remote. English — needed for the international market and documentation (Kafka, Flink, Confluent — English-speaking ecosystems). Streaming — a narrow specialisation, so the geography of openings is broader than it seems: specialist shortage works in the engineer's favour and expands remote opportunities.

Streaming — not a first role; people usually come from Data Engineering, backend development (especially JVM) or big data. Roadmap: 1) Base — distributed systems: what a distributed system is, consistency, fault tolerance, delivery guarantees (at-least-once / at-most-once / exactly-once). 2) Language — Java or Scala (most stream engines on JVM); Python as a supplement. 3) Apache Kafka thoroughly — topics, partitions, producers and consumers, consumer groups, offsets, replication, delivery guarantees; deploy locally and experiment. 4) Kafka ecosystem — Kafka Connect (integrations), Schema Registry (Avro / Protobuf and why message contracts are needed), operation basics. 5) Stream processing — start with Kafka Streams (simpler), then Apache Flink (the main skill — stateful processing, windows, event time, watermarks, exactly-once). 6) CDC — Debezium: capturing DB changes into a stream. 7) Concepts — event-driven architecture, event sourcing, idempotency, backpressure. 8) Infrastructure — Docker / Kubernetes, monitoring (Prometheus + Grafana), SQL, ClickHouse as a sink for streaming data. 9) End-to-end pet project: event source → Kafka → Flink processing (window aggregations) → write to ClickHouse → Grafana dashboard; add CDC from PostgreSQL via Debezium. Resources: book "Kafka: The Definitive Guide" (O'Reilly), Apache Kafka and Flink documentation, Confluent Developer (free courses and materials), data engineering and streaming courses (Otus, Karpov.Courses, Data Learn). In a Streaming engineer CV real streaming pipelines and an understanding of delivery guarantees are what's valued.

6 active open stream-processing positions in the Zorky sample — a narrow specialisation. The real market is broader: streaming duties and work with Kafka often appear in "Data Engineer", "Big Data Engineer", "Data Platform Engineer", "backend developer (event-driven)" openings — streaming isn't always called out as a separate term. Geography: Poland, the US, PK. Sources: hh.ru ("data engineer", "Kafka", "streaming engineer", "stream processing engineer"), Habr Career, getmatch, LinkedIn (international segment), Telegram (data engineering and Kafka communities). Demand concentrates in fintech, e-commerce, telco and large products — where real-time is critical. Time to close a Senior role — 6-12 weeks (shortage of distributed-systems specialists). Streaming — one of the highest-paying branches of Data Engineering.

A Senior Streaming engineer designs and operates streaming platforms and pipelines under high load. Distributed systems: deep understanding — consistency, fault tolerance, partitioning, delivery guarantees (at-least-once / exactly-once and their cost), CAP trade-offs; this is the foundation without which the rest doesn't work. Apache Kafka at operational level: cluster internals, partitioning and its impact on scaling and ordering, consumer groups and rebalancing, replication, KRaft, performance tuning, monitoring and incident analysis, schema evolution (Schema Registry). Stream processing: expert command of Flink (stateful processing, state management, checkpoints, event time vs processing time, watermarks, windowing, exactly-once), understanding of Kafka Streams and Spark Streaming and when to apply which. Architecture: designing event-driven systems, event sourcing, choosing delivery semantics per task, CDC pipelines (Debezium), idempotency, backpressure handling, designing for failures and reprocessing. Performance and reliability: tuning for throughput and latency, capacity planning, hot-partition handling, consumer-lag monitoring. Languages: confident JVM (Java / Scala), Python. Storage: ClickHouse and other streaming-data sinks, understanding how a stream connects to analytics and services. Infrastructure: Kubernetes, Docker, IaC, CI/CD, observability (Prometheus / Grafana). Data Engineering breadth: how streaming combines with batch (lambda / kappa architectures), data lakehouse. Communication: design decisions, reviews, mentoring, explaining trade-offs (e.g. the cost of exactly-once). English — for documentation and the international market. The main value of a Senior — the ability to design a streaming system with the required guarantees, which holds the load and behaves correctly under failures.