How We Build Listing Sites That Don't Slow Down

A real estate listing site has a specific way of getting slow that most other sites don't: the data set keeps growing, every listing wants a dozen high-resolution photos, and the primary interaction — filtering and browsing search results — happens to be the single most expensive query a database can run.

The mistake we see most often is treating search as an afterthought bolted onto a normal CRUD app. A query that joins price, location, square footage, and a dozen amenity filters against every active listing works fine with two hundred rows in a demo and falls over at twenty thousand, right around the point a site starts getting real traffic.

We push search into a system built for it rather than the primary database — filtering and ranking happen against an index designed for exactly this access pattern, while the database stays the source of truth. That split is the single biggest reason our listing sites stay fast as inventory grows instead of degrading quietly month over month.

Photos are the second bottleneck, and they're deceptive because they don't show up in a backend load test at all. A listing page with fifteen full-resolution photos loading synchronously is fast on a developer's fiber connection and unusable on a buyer's phone on a weak signal in a parking lot outside an open house. Every image gets served through a CDN at multiple sizes, lazy-loaded below the fold, and the map view — the page most likely to load dozens of thumbnails at once — gets its own aggressively compressed tier.

Pagination is where we've seen the most subtle performance bugs. Offset-based pagination looks correct in every test and gets progressively slower the deeper a user scrolls, because the database still has to count past every skipped row. We use cursor-based pagination on any listing feed that can grow past a few thousand rows, so page 50 is exactly as fast as page 1.

The map view deserves separate treatment from the list view, because it's a different performance problem: rendering thousands of pins without freezing the browser. We cluster markers server-side at low zoom levels and only fetch individual listing detail once a user has zoomed in far enough that the pin count is small enough to render smoothly.

None of this is exotic engineering. It's the ordinary discipline of building the expensive path — search, photos, pagination, map rendering — as its own deliberate system instead of assuming the same architecture that handles a contact form will hold up once a site has real inventory and real buyers filtering through it.