# Vinted The Engineering Blog from Vinted. These are the voyages of code tailors that help create Vinted. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How Vinted Serves Personalised Search Autocomplete DevFeed: [How Vinted Serves Personalised Search Autocomplete]() Original publisher: [Read original article]() Author: Justina Bartulevičienė Published: 2026-04-22T00:00:00Z Content type: article Language: en Sources: [Vinted]() Topics: [recommendation systems](), [data](), [systems](), [Learning]() Tags: [autocomplete](), [model](), [offline](), [performance](), [personalisation](), [pipeline](), [search]() ### AI overview Vinted describes the architecture and operation of its personalized search autocomplete service. The system generates candidate queries from product metadata and search logs, indexes and matches them with typo tolerance, and ranks suggestions using personalization and a Learning-to-Rank model. The service supports 24 languages and more than 50 country-language combinations, with 125 million queries and reported throughput of 4,700 queries per second at 31 ms P99. ### Source excerpt At Vinted, more than 20% of all search sessions now start with a click on an autocomplete suggestion. A few years ago, that number was below 8%. Autocomplete not only saves typing effort - it helps people discover listings they didn't know existed, and guides them toward successful searches. Today, across 24 languages and 50+ country-language combinations, we have a pool of 125 million different queries ready to suggest to users. Our service, svc-suggestions, runs on Vespa and matches and ranks 4,700 queries per second at 31 ms P99. ## Risk-Based Data Quality Testing for Reliable Finance Pipelines DevFeed: [Risk-Based Data Quality Testing for Reliable Finance Pipelines]() Original publisher: [Read original article]() Author: Jeremy Chia Published: 2026-03-11T00:00:00Z Content type: tutorial Language: en Sources: [Vinted]() Topics: [Data Quality](), [DataOps](), [Finance](), [Testing]() Tags: [data](), [data-quality](), [finance](), [migration](), [parquet](), [pipeline](), [pipelines](), [quality](), [reporting](), [schema](), [testing]() ### AI overview This article explains how Vinted addressed frequent upstream schema and format changes affecting finance reporting pipelines. It describes shifting testing closer to the source, applying materiality-based checks, and balancing data quality with pipeline reliability and timely availability. ### Source excerpt Upstream schema changes were breaking our finance pipelines daily. With monthly reporting deadlines looming, we needed to balance data quality with pipeline reliability. Here's how we solved it without compromising either. ## From Dagger to Metro DevFeed: [From Dagger to Metro]() Original publisher: [Read original article]() Author: Andrius Semionovas Published: 2026-02-12T00:00:00Z Content type: article Language: en Sources: [Vinted]() Topics: [Dependency injection](), [Android](), [migration](), [Kotlin](), [Dagger](), [interoperability](), [Compiler](), [modules](), [Gradle]() Tags: [android](), [compatibility](), [compilation](), [dagger](), [dependency-injection](), [gradle](), [interoperability](), [kotlin](), [migration](), [modules]() ### AI overview Vinted's Android developers describe their migration from Dagger and related dependency-injection tools to Metro. The article covers their large, modular codebase, Anvil's maintenance status and K2 migration pressure, and Metro's interoperability with Dagger, Anvil, and kotlin-inject. ### Source excerpt Metro - modern and kotlin injection framework created by Zac Sweers. And we, Android developers at Vinted, officially and fully migrated to it! It was quite a bumpy ride for our huge codebase. Our story begins... ## From Bash to Bliss: Scaling Vespa Operations with Temporal DevFeed: [From Bash to Bliss: Scaling Vespa Operations with Temporal]() Original publisher: [Read original article]() Author: Martynas Jakimčikas Published: 2026-01-21T00:00:00Z Content type: article Language: en Sources: [Vinted]() Topics: [Platform Engineering](), [Orchestration](), [Scripting, bash](), [Automation](), [health checks](), [upgrade]() Tags: [automation](), [commands](), [complexity](), [health-checks](), [maintenance](), [orchestration](), [platform](), [scheduled](), [script](), [self-service](), [upgrade]() ### AI overview This article describes how Vinted's platform team handled growing maintenance demands for its Vespa search infrastructure. As the environment expanded from hundreds to more than a thousand nodes and included many deployments, Bash scripts and Knife commands became difficult to manage. The team moved toward durable orchestration with Temporal, automated health checks, scheduled upgrades, and self-service guardrails. ### Source excerpt Growing platform - Growing maintenance Keeping the Lights On (KTLO) is an essential, yet often taxing, part of a platform engineer's role. It represents the routine operational work required to keep the business running and the platform stable. For our team, this primarily involves maintenance on our search engine, Vespa - ranging from version upgrades and service restarts to draining traffic from nodes for hardware replacements. ## Building a Global, Event-Driven Platform: Our Ongoing Journey, Part 1 DevFeed: [Building a Global, Event-Driven Platform: Our Ongoing Journey, Part 1]() Original publisher: [Read original article]() Author: Dejan Menges Published: 2026-01-09T00:00:00Z Content type: article Language: en Sources: [Vinted]() Topics: [event driven](), [Domain-driven design (DDD)](), [Latency](), [Software](), [Development]() Tags: [architecture](), [ddd](), [development](), [distributed](), [domain-driven-design](), [event-driven](), [latency](), [patterns](), [scale](), [software]() ### AI overview Vinted describes why its growing platform outgrew a monolithic architecture, citing regional latency, unpredictable load, large failure domains, and tangled responsibilities. The article outlines the use of Domain-Driven Design to identify domains and guide team and architecture restructuring, followed by a move toward event-driven communication and sagas. ### Source excerpt A few years ago, our platform reached a point where the way we'd always built software simply wasn't enough anymore. The monolith that powered our early success had served us well, but as the business expanded across the continent, it started showing real limits. Global growth forced us to confront problems we couldn't ignore: latency across regions, unpredictable load patterns, and an architecture that didn't match the scale of the company. We needed to rethink how the entire system worked, from the shape of our data to the boundaries between teams. ## Building a Global, Event-Driven Platform: Our Ongoing Journey, Part 2 DevFeed: [Building a Global, Event-Driven Platform: Our Ongoing Journey, Part 2]() Original publisher: [Read original article]() Author: Dejan Menges Published: 2026-01-09T00:00:00Z Content type: article Language: en Sources: [Vinted]() Topics: [event driven](), [Replication](), [data](), [Domain-driven design (DDD)](), [Network]() Tags: [architecture](), [consistency](), [domain-driven-design](), [event-driven](), [network](), [replication]() ### AI overview Part 2 of Vinted's engineering account describes operating an event-driven platform across continents. It explains the choice to centralize writes while replicating read-only projections globally, accepting eventual consistency to provide local reads and avoid the complexity and cost of multi-writer sharding. The article also discusses designing projections to tolerate replication delays and partial failures. ### Source excerpt In the first part, we described how growth pushed us beyond the limits of the monolith and forced us to rethink our architecture from the ground up. We explored how Domain Driven Design helped us uncover clear boundaries, and how shifting from synchronous calls to events and sagas changed the way the system behaves under real distributed conditions. With that foundation in place, we can now focus on what it takes to run this platform reliably across continents. ## How Vinted Standardizes Large-Scale Decentralized Data Pipelines DevFeed: [How Vinted Standardizes Large-Scale Decentralized Data Pipelines]() Original publisher: [Read original article]() Author: Oscar Ligthart Published: 2025-12-29T00:00:00Z Content type: article Language: en Sources: [Vinted]() Topics: [Data Infrastructure](), [Orchestration](), [airflow](), [Cloud]() Tags: [airflow](), [business-logic](), [cloud](), [data](), [dependencies](), [domain](), [gcp](), [infrastructure](), [orchestration](), [pipelines](), [scale]() ### AI overview Vinted describes its migration to cloud-based data infrastructure and the challenges of coordinating dependencies across decentralized teams and domains. The article explains why relying on teams to hand-craft Airflow DAGs would add unnecessary complexity, and discusses adapting the conventional dbt-with-Airflow approach to Vinted's scale and cost constraints. ### Source excerpt TL;DR: How Vinted standardizes large-scale decentralized data pipelines. ## Dense Retrieval DevFeed: [Dense Retrieval]() Original publisher: [Read original article]() Author: Laurynas Jasiukėnas Published: 2025-11-18T00:00:00Z Content type: article Language: en Sources: [Vinted]() Topics: [Embeddings](), [Machine learning](), [Fine-tuning](), [rust-ai]() Tags: [business](), [e-commerce](), [embedding](), [experimentation](), [fine-tuning](), [images](), [metrics](), [model](), [retrieval](), [search](), [two-tower-model](), [vector]() ### AI overview Vinted Engineering describes integrating dense embedding-based retrieval into its multilingual e-commerce search system. The approach uses a two-tower model with query and item embeddings, and the article covers experimentation, model improvements, and engineering work that led to full enablement after approximately 50 A/B tests. ### Source excerpt TL;DR: integrating embedding-based retrieval into the e-commerce search application is a significant undertaking. ## Reducing Vespa Ranking-Feature Latency During Frequent Data Redistribution DevFeed: [Reducing Vespa Ranking-Feature Latency During Frequent Data Redistribution]() Original publisher: [Read original article]() Author: Dainius Jocas Published: 2025-11-06T00:00:00Z Content type: article Language: en Sources: [Vinted]() Topics: [Latency](), [Redis](), [data]() Tags: [data](), [latency](), [logs](), [network](), [redis]() ### AI overview Vinted describes using Vespa to store and retrieve ranking features after Redis became a bottleneck, then investigating p99 latency spikes after large feeding bursts. The article focuses on a Vespa optimization for data that is frequently redistributed. ### Source excerpt TL:DR: When required data can be encoded with match-features, Vespa can apply a new optimisation, which can be a lifesaver when data is frequently redistributed. ## Investigation: Identical Servers, Different Performance DevFeed: [Investigation: Identical Servers, Different Performance]() Original publisher: [Read original article]() Author: Simonas Rupšys Published: 2025-07-15T00:00:00Z Content type: article Language: en Sources: [Vinted]() Topics: [Redis](), [Latency](), [Linux](), [Benchmark](), [cpu](), [Kernel](), [servers]() Tags: [benchmark](), [cpu](), [hardware](), [kernel](), [latency](), [linux](), [performance](), [redis](), [servers](), [technical]() ### AI overview The article investigates inconsistent Redis performance across otherwise identical servers. It finds that servers using the slower HPET Linux clocksource instead of TSC had higher Redis latency and CPU usage, and it explains how to detect and change the clocksource and prevent unintended changes. ### Source excerpt Inconsistent Redis performance was observed across a fleet of otherwise identical servers. After investigation, we discovered that differences in Linux system clocksource settings - specifically, servers running the slower HPET clocksource instead of the default TSC - led to significant increases in Redis latency and CPU usage.