Beyond Watermarks: Custom Flink Operators for Feature-Trigger Synchronization

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 don't fit.

We finish on the operational realities the design has to hold up against in production: backfills, redeployments, and designing for the worst case rather than the happy path — plus the monitoring that makes timeout tuning and failure diagnosis possible.

Takeaways: a checklist for deciding whether cross-job alignment is needed at all; the operator patterns and timing analysis behind two in-job designs; a custom ingestion-notification operator that goes beyond what watermarks and built-in joins offer; and the operational habits that keep it correct.