Miro Perdoch

Engineering & Architecture

Building for 1.7 Million Addresses: Lessons in Data, Search and SEO

What I learned from making 1.7 million address records feel like one simple search.

Miro Perdoch 7 min read

Editorial illustration of a network of data points representing address records
At work, still learning.

You enter your address, click Search, and expect an answer. Is internet available at my home? What technology can I get? It should take just a few seconds.

But what if the website needs to find that answer among more than 1.7 million address records?

That was one of the interesting challenges I worked on while rebuilding Dostupný Internet, a platform helping people check internet availability across Slovakia.

From the visitor's perspective, it is a simple address search. Behind the scenes, it is a completely different story. And surprisingly, the biggest challenge was not making it fast.

1.7 million addresses. And plenty of surprises.

You would expect an address database to be relatively straightforward. A city, a street, a building number. What could go wrong?

Quite a lot, actually.

Different data sources describe the same location differently. Some addresses appear more than once. Others have missing information, inconsistent names or identifiers that do not match as expected.

With a few hundred addresses, these problems might be easy to fix manually. With 1.7 million records, even a small percentage of problematic entries becomes a significant challenge.

I learned that the first step was not writing a faster search. It was understanding the data, cleaning it up and making sure the application could trust the results.

There is also an important distinction between not having information and knowing that a service is unavailable. Those are two very different answers, and a trustworthy website should never confuse them.

More pages do not mean a better website

Here is another interesting problem.

If you have 1.7 million addresses, does that mean you should create 1.7 million pages for Google?

Not necessarily.

Some addresses are duplicates. Some have no meaningful availability information. Others are useful when someone searches directly on the website, but would add little value as individual Google search results.

This is where software development meets SEO.

We needed to think about two different experiences: helping visitors find an address on the website, and deciding which address pages genuinely deserve to appear in search engines.

The goal was never to produce the largest possible number of pages. It was to make useful information easier to discover.

More records do not automatically mean more useful pages. The real goal is a smaller number of reliable answers.

Keeping things simple takes a lot of work

Once the address data is organised, another question appears: how do you make searching through it feel effortless?

A traditional database is excellent at storing structured information. A dedicated search engine is better suited to quickly finding relevant results, even when someone types only part of an address.

Using both makes sense. But it also means keeping everything consistent.

When address information changes, the search results need to reflect those changes. When a large import fails, there must be a way to investigate and recover. And when new data is ready, it should reach visitors without disrupting the website.

These are not particularly exciting features to show in a portfolio screenshot.

Yet they are often the difference between a website that works during a demonstration and one that people can depend on every day.

The visitor should never need to know any of this

This is probably my favourite part of working on complex digital products.

Behind a simple search field, there can be millions of records, different data providers, search indexes, background processes and countless small decisions about what information should be displayed.

But none of that should become the visitor's problem.

Someone checking internet availability does not want to understand databases, duplicate records or search engine architecture.

They want to know whether they can get internet at their address and what to do next.

And if we have designed the system well, that is exactly the experience they get.

What scale taught me

Working with a large address dataset did not fundamentally change my view of good software engineering.

It reinforced something I have learned repeatedly throughout my career: the larger and more complex a system becomes, the more important simplicity, consistency and attention to detail are.

Users do not care how many records sit behind a search box. They want to enter an address, understand the result and know what they can do next.

The job is to make all the complexity behind that experience feel simple, without pretending that the complexity has disappeared.

For me, that is the most rewarding kind of engineering: making complicated systems dependable enough that the user rarely has to think about them.


This article shares general lessons rather than internal implementation details. You can find more about the project in my Dostupný Internet case study, or read why I believe developers benefit from understanding analytics and marketing.