SeLoger / MeilleursAgents

I was based at the Aix-en-Provence office, with regular trips to Paris, in the Geo team. Our job: give every site in the group the building block that turns what a user types (“Paris 9”, “Aix”, “rue de la République”) into a precise place to run a listing search on.

A fast autocomplete, frozen in place

The original autocomplete was an in-house engine written in C# by former team members. It was mature and very fast, built on a complex algorithm that relied on Levenshtein distance among other things. Its weakness came from its very design: it loaded all the data into memory, which made it very memory-hungry, and once that cache was built, updating the reference data was extremely hard.

In practice, the team could no longer maintain it or make it evolve. We had to rethink everything under two constraints: keep response times as good as the legacy engine, and finally make data updates painless.

Starting from scratch

We chose to build on OpenStreetMap. Python scripts and hooks regularly ingested the OSM dumps into a PostgreSQL database. On top of that public data came SeLoger’s own layers, with details missing from the public dumps, such as neighborhood boundaries.

Everything was first stored as-is, as raw data. An event-driven architecture on AWS, using SNS and SQS, then pushed every change to read models suited to each use case:

• PostgreSQL and its full-text search, for some cases
• Elasticsearch, for autocomplete
• in-memory read models inside .NET services, for the most critical calls, which answered in about 10 ms.

On the edge, an AWS API Gateway routed each endpoint to the right service, and part of the business logic lived in Lambda functions. The whole platform ran as microservices, containerized with Docker and deployed on Kubernetes.

Pushing Elasticsearch to its limits

The autocomplete endpoint took the most research. We constantly had to trade off index size, result relevance and response time. We worked along several lines:

• a priority based on each layer’s administrative level (country, region, department, city, neighborhood), so the right place comes up first
• phonetic relevance, tolerating typos through Levenshtein distance
• aliases, a concept I introduced: “9e arrondissement”, “9 arr” or “9ième” all return the same result.

JMeter load tests validated each step and let us tune the configuration before any problem reached production.

Demos that finally spoke

We worked in Scrum. Historically, the team only showed APIs and purely technical items at sprint reviews. Stakeholders struggled to see what had actually been done, even though a huge amount of work moved forward every sprint.

I proposed an Angular demo app wired to our services, and I built it. Overnight, demos became concrete: you typed an address, watched the results appear and understood what had changed. The feedback followed, with regular praise for our progress.

Merging with MeilleursAgents

After AVIV acquired MeilleursAgents, my Geo team merged with MeilleursAgents’ team. We came from two different worlds. Ours was about ingesting large volumes of data, real-time updates and fast responses. MeilleursAgents’ core was about enriching data through data science, also largely built on Python ingestion. From then on, I worked in Python as much as in C#.

We merged the layers MeilleursAgents brought with our own, looking for compromises, because each site in the group had its own rules. Some only allowed searching for neighborhoods, others allowed everything, others everything except streets. In the end, the reference service powered eight AVIV Group sites, including SeLoger, Logic-Immo, Belles Demeures, MySeLogerPro, MeilleursAgents and Immowelt.