Uddeshhya

Problem — In a blood-donation emergency, someone needs to find a matching donor by blood group and city fast — every filtered lookup hitting MongoDB directly adds latency exactly when it matters most, and listing every donor's phone number in the open isn't something a volunteer directory should do either.

Approach — The blood-group + city donor query is cached in Redis and invalidated on new registrations, so lookups stay fast without re-scanning the donor collection on every search — with contact details released through a request step rather than published on the page.

Problem — Every volunteer and blood donation earns a certificate with that person's name and date on it — generating those by hand doesn't scale past a handful of people, and a donation drive can produce 50+ certificate requests in a single afternoon.

Approach — Templated PDF generation triggered on registration/donation confirmation, so certificates are produced and downloadable automatically instead of assembled manually per person, one at a time, after every drive.

Problem — The NGO's own team, not developers, needs to publish new projects, gallery photos, and blog posts — and shouldn't need a code deploy to do it.

Approach — Modeled projects, gallery, and blog content as data the frontend renders, so the team edits content directly instead of routing every update through me. Deliberately skipped a message queue and heavier caching here — a volunteer-run site with no concurrent-checkout problem doesn't need it, and the boring version is the one the NGO's team can reason about without me.