Whydonate Donation API Scale

Challenge

Donation platforms have uneven traffic: quiet periods, sudden campaign spikes, payment-adjacent workflows, file and media storage needs, queue-backed background work, and search queries competing for backend capacity.

Approach

I built and improved Cloudflare Workers API paths, TypeScript service boundaries, queue-backed background processing, R2-backed storage flows, PlanetScale MySQL data access, and Typesense search behavior so high-volume traffic did not overload core fundraising workflows.

Result

The platform stayed stable under sustained donor traffic while supporting donation workflows, Cloudflare-native backend operations, and fast search/filtering through Typesense.

Proof Points

• 4M+ API requests/day
• Cloudflare Workers TypeScript APIs
• Cloudflare Pages, R2, and Queues
• PlanetScale MySQL and Typesense search

Architecture Decisions

• Built the backend around Cloudflare Workers with TypeScript so request handling, API routing, validation, and integration logic could run close to users.
• Used Cloudflare Pages for frontend delivery, R2 for object storage needs, and Cloudflare Queues for background work that should not block donor-facing requests.
• Kept PlanetScale MySQL as the transactional database layer and used Typesense for fast search paths instead of overloading the primary database with search behavior.
• Focused on the API paths that mattered during campaign traffic spikes instead of treating every endpoint as equally risky.
• Kept changes incremental because donation platforms cannot afford risky rewrites during active fundraising periods.

Implementation Notes

The scaling work focused on the places where real donor traffic would hurt first: campaign pages, donation-related API paths, currency-aware views, queued background jobs, object storage flows, and search queries that could compete during traffic spikes.

I treated Cloudflare Workers, Pages, R2, Queues, PlanetScale MySQL, and Typesense as one production system. Workers handled the API edge, queues protected slower background work, R2 handled storage concerns, PlanetScale owned transactional data, and Typesense served search-oriented reads.

The safest path was incremental improvement. Donation platforms cannot pause fundraising while the backend is rewritten, so the work had to preserve existing behavior while making the high-volume paths more predictable.

Risks Avoided

• A broad rewrite that would create launch risk during active campaigns.
• Donor-facing requests waiting on slower background processing that belonged in Cloudflare Queues.
• Search behavior putting unnecessary pressure on the PlanetScale MySQL database instead of Typesense.
• Cloudflare being treated as a magic fix instead of a full stack with Workers, Pages, R2, Queues, database, and search responsibilities.
• Small Workers endpoint inefficiencies becoming expensive at 4M+ API requests/day.

Cloudflare and AWS Relevance

• Used Cloudflare Workers with TypeScript for high-volume API paths, request handling, validation, and integration logic.
• Used Cloudflare Pages, R2, and Queues as part of the production architecture rather than treating Cloudflare as only a CDN.
• Kept transactional data in PlanetScale MySQL and search-specific reads in Typesense so each backend component had a clear job.
• Evaluated performance as a system problem: Workers behavior, queue boundaries, R2 storage paths, PlanetScale access, Typesense search, and product traffic patterns together.

Client Questions