Page MenuHomePhabricator

Make Contribution Tracking not a SPOF
Open, Needs TriagePublic


Payments will gown down in flames if the fr-write database goes away, we should provide redundancy. The only requirement is a connection for contribution tracking.

Possible solutions:

  • Maybe create a c_t table on payments1 with an auto-increment way above the threshold and backfill once db1008 comes back? - Wait, do you mean backfill the real c_t table, and nuke the table on payments1?
  • Start using UUIDs so this requirement no longer exists - I feel like I'm failing to remember some shining good reason this won't work either.
  • Recent contribution_tracking can be served using a redundant key/value store such as Redis. Archived contribution_tracking can still be served from mysql.

Event Timeline

awight created this task.Jan 8 2015, 10:23 PM
awight raised the priority of this task from to Needs Triage.
awight updated the task description. (Show Details)
awight moved this task to DI Refactor on the Fundraising-Backlog-Old board.
awight added a subscriber: awight.
awight added a comment.EditedJun 3 2015, 8:33 PM

We should switch to logging CT events as a historical log rather than a snapshot. I can confirm that paymentswiki never needs to read from CT, so this would be a security as well as stability win.

Use Redis as a sequence generator for ct_id, and store events as a list under that key.

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 29 2015, 12:31 AM
awight set Security to None.
DStrine added a subscriber: DStrine.Jun 6 2017, 4:43 PM

We discussed this in an offsite. Some notes are here:

DStrine removed a subscriber: awight.Jun 22 2017, 9:13 PM