Funraisin

Matched giving lets a sponsor match donations up to a cap, and strict handling is meant to stop matching once the cap is reached. It did not hold under concurrency. Two donations submitted at the same instant could both read the remaining match pool before either had written its own match, so both matched and the sponsor was charged past the cap.

I moved the calculation into the model used by donation pages, then added a per-pool MySQL named lock around the calculation and matched-donation insert. I applied the lock across seven donation paths and wrapped each use in try/finally so it releases when processing succeeds or throws.

Matched-giving requests for the same pool now pass through one locked calculation and insert path. This was a manual check, not a load test. I submitted two donations to the same pool at the same moment from separate browser sessions, then read the donation rows back to see that one match calculation had landed and the total had stayed under the sponsor's cap. That covers a genuine concurrent submission and says nothing about sustained volume.

Concurrent raffle requests could both try to create the sale linked to the same purchase. A fixed delay hid the race without controlling which request created the record.

I added a database transaction and row-level lock around sale creation. When another request owns the creation path, bounded polling looks for the resulting sale instead of creating a duplicate.

Competing requests now resolve to one sale through a controlled creation path. I reproduced the race with a script that replayed a completed payment's PayPal webhook payload as 20 concurrent requests. Before the fix that left 21 sale records: 1 from the genuine request and 20 from the replay. After the fix it left 1. Duplicates that had only become less frequent would still have shown up in that count.

Advanced PURLs give each supporter a personal campaign link with pre-filled amounts, generated in bulk from an import. The import failed on the first attempt and succeeded on the second. The first attempt left partial state behind, causing a retry to behave differently from a clean first run. The import path was not safely repeatable.

I worked the import path and record hashing so bulk generation could safely resume after a partial run instead of treating a retry as a fresh import. Existing records from the previous attempt were recognized and reused, allowing subsequent attempts to continue processing the remaining data without conflicting with partial state.

I also made expiry and usage mode configurable, not implicit, made expired PURLs load their page and form normally instead of erroring, and added search to the admin interface, which was unusable once an account held thousands of records.

Imports became safely repeatable after a partial run. Using the same file, I retried against the partial state and confirmed that existing hashed records were reused while processing continued for the remaining records without conflicts. Expired links degrade to a normal page instead of an error, and administrators can find a record without paging through the whole set.

Intelligent Giving suggests donation amounts. The logic is small, but it had to reach every donation form: platform-level and event-level settings rendering correctly across all four template generations. Releasing everywhere at once would have changed donation-form behavior on every platform simultaneously.

I implemented the settings across that matrix and put the feature behind a beta switch so it could be enabled per platform instead of globally. Most of the follow-up work was configuration failing on one specific path. Defaults did not update, a preview did not reflect a change, and handles did not resolve when an event relied on platform defaults.

Each platform could enable the feature independently. I verified that the disabled preview preserved its manually configured handles and that the enabled preview resolved Intelligent Giving defaults, while reported fallback defects were fixed in the affected template paths.

A client syncing to Salesforce found donations staying attached to the wrong campaign after a fundraiser was moved to a new team. Nothing errored, and the platform's own screens were correct.

Moving a fundraiser's donations updated the team reference on those records but did not touch their last-updated timestamp. The Salesforce sync uses that timestamp to decide what has changed, so from its side nothing had. Finding it meant reasoning about how change detection worked, not reading a stack trace.

Updating the fundraiser's team now also updates the change signal consumed by the Salesforce synchronization path. The next sync can therefore reprocess the affected donations instead of leaving them attached to the previous campaign. I never watched a sync reprocess those donations. I confirmed that the timestamp gets updated, and the reprocessing follows from how the sync decides what has changed.