Problem
Liveizy's property listings needed fast, filterable search across a growing inventory — the kind of
query load that gets slow fast on a naive relational LIKE search as
listings scale.
This got more complex as Liveizy expanded into Uganda: the same platform now had to serve listings across two currencies and two markets.
Architecture
-
A dedicated search layer over querying the primary database
Built the search layer in Go paired with Elasticsearch, offloading search, filter, and ranking work from the primary database to a purpose-built search index — Go for low-latency request handling, Elasticsearch for the inverted-index search Postgres isn't built for.
-
Multi-currency over a second deployment per market
Migrated the platform to a multi-currency setup to support the Uganda expansion, serving both markets from one platform rather than forking infrastructure per country.
-
Microservices over a shared runtime
Search sits inside a broader microservices architecture, so peak traffic in one part of the system doesn't take the rest of it down with it.
Outcome
The search rewrite cut query response times by over 60%. As part of the broader microservices architecture, it contributed to a 40% reduction in system downtime during peak traffic and a 25% increase in active users within six months — while scaling to 2,000+ properties across both markets with multi-currency support.