Home/ Questions/Q 9088749
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-16T21:58:26+00:00

Are there any design patterns related to processing important financial operations so that there’s

  • 0

Are there any “design patterns” related to processing important financial operations so that there’s no way that a local database can become out of sync because of some errors ?

Example:

A financial transaction record is created in a local db, then a request is sent to a remote payment API endpoint to charge a customer. Pseudocode:

record = TransactionRecord.create(timestamp=DateTime.now, amount=billed_amount, status=Processing)
response = Request.post(url=remote_url, data=record.post_data)
if response.ok:
    record.mark_as_ok()
else:
    record.mark_failed()

Now, even if I handle errors that can be returned by the remote payment service a lot of other bad things can still happen: DB server can go down, network connection can go down etc., at arbitrary points in time.

In the above code the DB server can become inaccessible right after creating the transaction record, so it might not be possible to mark that record as ok, even if the financial transaction itself has been performed successfuly by the remote service.
In other words: customer is charged but we don’t have that booked..

This can be worked around in a number of ways – by periodically syncing with the remote service, by investigating TransactionReturn-s which are being processed but are older than e.g. 10 minutes or an hour.

But my question is if there are some well established patterns for handling such situations (where money is involved, so everything should work properly “all the time”) ?

PS. I’m not sure what tags should I use for this question, feel free to re-tag it.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I don’t think there is any ‘design pattern’ to address cases such as database connection going down or network connection going down as it happens in your scenario. Any of those two scenarios are major fault events and would most likely require manual intervention.

    There is not much coding you can do to address them other than being defensive by doing proper error checking, providing proper notifications to support and automatically disabling functionality which does not work (if the application detects that the payment service is down then ‘Submit payment’ button should be disabled).

    You will be able to cut down significantly on support if you do proper error handling and state management. In your case, the transaction record would have to change its state from Pending -> Submitted -> Processed or Rejected or something like this.

    Also, not every service provides functionality to for syncing up.

    • 0