Csanád Bakos

At Vinted — Europe's largest second-hand marketplace — Trust & Safety scores millions of events per second to catch malicious users and policy-violating content in seconds. Each trigger needs features to decide. If features lag, decisions are made on stale data. Watermarks align time within a Flink job — not across the feature and trigger jobs that meet at a Feature Store. This talk is about closing that gap with custom operators, and — more importantly — the decisions made before writing one. We'll work through the characteristics that drive the design (velocity, cardinality, lateness, latency budget, missing-data policy, delivery semantics) and the one question that dominates the rest: is this feature only for this trigger, or reusable? That axis decides whether alignment stays in-job or crosses a job boundary. From there, two production walkthroughs of in-job enrichment show how the framework picks the operator — and what timing cases each must survive. Then the pivot: once a feature is reusable, a Feature Store lookup at trigger time becomes a coin flip on freshness. We close that gap with a custom operator built on ingestion notifications, and show why Flink's built-in joins…

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.

To catch malicious behavior on Europe's largest second-hand marketplace, every second matters - but so does accuracy, which relies on data completeness. At Vinted, within the Trust domain, we process millions of events daily to enable ML models and rule engines to detect malicious users and policy-violating content in real-time. Using an event-driven architecture, we rely on events to trigger rule evaluations. These also require other computed features in a timely manner for accurate detection results. If these lag behind, models operate on stale or even missing data. In this talk, I will first elaborate on why built-in event-time processing operators in Flink didn’t meet the requirements to guarantee feature-trigger alignment. For starters, Flink only has (temporal) inner joins out of the box. Then, I will share the custom solutions we built. In particular, you will learn two distinct patterns, suitable for different data velocities and scenarios. Pattern 1: Feature Store and Ingestion Notification Alignment We have several complex features computed by dedicated pipelines, writing to our Feature Store. Here, we rely on ingestion notifications to signal feature availability. We…