CS-01 · CASE STUDY · 2024–2026
RealEstateAPI — property search at production scale
Operating RealEstateAPI's property-data platform serving tens of millions of requests a week — pagination correctness, latency regressions, and billing systems that have to be right.
- Role
- Software engineer
- Year
- 2024–2026
- Stack
- Node.js · Elasticsearch · GCP · Heroku · Grafana/Loki
The system
RealEstateAPI is a property-data API platform: search, detail lookups, and bulk endpoints over a corpus of US property records, backed by Elasticsearch. Tens of millions of requests a week, hundreds of customer organizations, real-time billing across subscription and pay-as-you-go models.
Things that had to be solved
Pagination that tells the truth. Elasticsearch’s default tiebreaker is unstable on a live-write index — segment merges renumber documents, so customers paging through results could see duplicates across pages. The naive fix (a stable sort on every query) regressed p95 latency 3× because it killed the fast no-sort path on the highest-volume queries. The shipped fix applies the stable tiebreaker only on paginated requests, keeping page-one queries on the fast path.
Billing that can’t be wrong. Metered usage across two billing models, where a bug means either overcharging customers or leaking revenue. Flat-rate request modes, per-record billing, exclusion rules for metadata queries — all of it reconciled against a wallet system in real time.
Knowing what production is doing. Deploy verification with a changed-vs-unchanged endpoint discriminator to separate code regressions from cluster-wide load events; test-traffic exclusion so synthetic monitoring doesn’t pollute customer-facing latency metrics.
What it taught me
Production correctness lives in the details nobody sees: sort tiebreakers, metering edge cases, the difference between “the metric moved” and “my code moved it.”