2026-09-10 –, Room 2 (350)
In online marketplaces, bad actors utilize automation to scale fraud quickly. ML models can catch it, but they need features computed based on user behavior — updated in a timely manner. Batch features are too slow — fraud spreads before the next scheduled job runs.
Drawing from production experience operating 25+ streaming jobs for a large online second-hand marketplace, we will walk through the architecture and key design decisions behind our streaming platform powering ML fraud detection. This is composed of Kafka topics, Flink jobs, a feature store serving real-time inference and a data warehouse for historical data for model training. We will touch upon the strategies to bridge the gap between raw streaming output and training-ready data.
We will also explore fundamental differences between streaming and batch feature engineering. From bounded vs unbounded data to stateful operators, fault tolerance, and scaling — we will cover what makes Flink excellent for real-time processing. When real-time isn't needed, Flink can do batch too — it's just probably not the best choice, e.g. dbt with your favourite data warehouse can do better — we will shed some light on why.
The principles shared will help you evaluate what to look for in a stream processing framework and whether you need Flink's capabilities for your own use cases. Aimed at data engineers, ML engineers, and data scientists interested in streaming vs batch trade-offs, fraud detection, or trust & safety.
You will walk away with:
- Understanding of a production tested architecture for serving streaming features to both real-time inference and model training without duplicate computation
- Appreciate when real-time features add value vs when batch is the right tool
- A sense of the operational challenges — to help you evaluate whether real-time is worth the cost and effort for your specific use case
This talk draws from production experience building and operating a real-time feature platform at a large online second-hand marketplace. The platform runs dozens of independent Apache Flink streaming jobs computing user behavior signals for ML-based fraud detection, processing millions of events per second.
Outline with timing (25 min talk + 5 min Q&A):
- Why real-time features for fraud detection (5 min)
- The fraud timeline: what happens between a bad actor's first action and detection
- Batch features introduce a blind spot of tens of minutes to hours. Streaming closes it to seconds
When the added complexity of real-time is justified — and when batch is good enough
Architecture: from event streams to inference and training (10 min)
- Event-driven pipeline: CDC and event streams from Kafka → Flink processing → Feature Store → ML inference
- Reactive triggers: ML re-scoring fired automatically based on feature updates or specific user actions
Reusing streaming output for model training: sinking features to a data warehouse. Why a raw dump isn't suitable for training and the strategies we applied to make it work alongside batch-produced datasets (backfills, deduplication, data cleaning)
Streaming vs batch feature engineering (7 min)
- Fundamental differences: bounded vs unbounded data, incremental vs full recomputation
- Key Flink building blocks that make real-time work: stateful operators, fault tolerance, exactly-once guarantees, horizontal scaling
- Operational realities: checkpointing, state management, deployment complexity
Flink can also do batch — but when real-time isn't needed, dbt with your favourite data warehouse is likely a better fit — will explore why
Wrap-up and Q&A (3 min + 5 min)
- Key lessons and challenges that remain
- Open discussion
Approach: Practical and experience-driven. Architecture diagrams, concrete production examples, and honest discussion of trade-offs. No live coding or demos.
Required background knowledge: Basic understanding of what ML features are. Familiarity with Kafka or event-driven systems is helpful but not required — key concepts will be briefly introduced.
Scope: We focus on the architecture and trade-offs of real-time feature engineering for ML, not on Flink APIs or framework internals. The talk is grounded in a fraud detection use case but the patterns are applicable to any domain where feature freshness matters. We will not compare Flink to other stream processing frameworks directly, but the principles shared will help attendees evaluate what capabilities matter for their own use cases.
Csanád is a Data Engineer at Vinted, where he builds and maintains dozens of Apache Flink streaming jobs powering real-time feature engineering for Trust & Safety. His work ensures that ML models and rule engines have timely, complete data to detect malicious users on Europe's largest second-hand marketplace — driving thousands of automated actions per hour including account blocks, listing removals, and manual review escalations. He has spoken at Confluent's real-time data community meetup in London and he’s a presenter at Current 2026 London on custom Flink operators for feature-trigger synchronization. Csanád holds a Master's degree in Computer Science from the Delft University of Technology, where he graduated cum laude.