Matching Blood Donors by GPS: The Geospatial Query Design Behind GeoBlood
This story was originally published on HackerNoon at: https://hackernoon.com/matching-blood-donors-by-gps-the-geospatial-query-design-behind-geoblood. How GeoBlood matches blood donors in real time: MongoDB 2dsphere indexes, $geoNear vs $geoWithin, staged radius expansion, and donor location privacy. Check more stories related to programming at: https://hackernoon.com/c/programming. You can also check exclusive content about #mongodb, #geospatial, #software-engineering, #backend-development, #database-indexing, #nodejs, #system-design, #tech-for-good, and more. This story was written by: @obaid03. Learn more about this writer by checking @obaid03's about page, and for more stories, please visit hackernoon.com. Blood donor matching looks like a proximity search and is not one. This is how the query works at GeoBlood, a nonprofit platform live in four countries: what a MongoDB 2dsphere index actually does with S2 cell coverings, when to reach for $near versus $geoWithin versus $geoNear, and the trap where putting your filter in a separate $match instead of inside $geoNear's query makes the stage materialise everything in the radius before discarding it. Then the domain part. ABO compatibility is a matrix, not an equality check, so widening the pool means every request starts recruiting O negative donors, and your ranking has to protect the scarcest type instead of spending it. Radius expansion runs in timed waves over annuli so nobody gets four pushes for one request. And donor locations are matched precisely but published coarsely, because random per-request jitter is defeated by averaging forty samples.
