Fundraising tech/Contribution tracking

Jump to navigation Jump to search

Contribution tracking, as of early 2018, is the last piece of our payments infrastructure that ties the payments-wiki frontend to the database server in the backend. We want to be able to take the backend db server down for maintenance without needing to shut down the payments frontend. To do this, we will have to stop creating contribution_tracking rows directly from the wikis and move to a queue-based insert system.

Ideally we will still be able to create the ct_id on the front end, possibly using a sequence generated by redis.

Cut-off dates: TODO: till when can we safely keep working on this?

Sequence generator should have an interface and be provided by a configurable class. SmashPig would be a good place to create these.

Everywhere that inserts contribution tracking data will need to be altered to use the sequence generator to get the new ID before inserting. Inserting contribution tracking data from the frontend will be replaced with inserts into a new queue (to be defined in SmashPig).

Should backend contribution inserts send ct data to the queue too?

  • pro: keeps row insert order closer to ID sequence order
  • con: might mean more complicated refactoring if the c_t table is read from later in the same process. This read would be a bit redundant and maybe SHOULD be removed.

Everywhere that READS contribution tracking data should be examined to determine if it needs to deal with the situation in which the c_t queue has not yet been consumed.

Donations queue consumer updates contribution tracking - if donation comes in with a ct_id but without the row existing yet, re-queue for later processing.