2
Lets say there is a service in which users can have a few satoshis but are also able to deposite/withdraw satoshis by paying/sending a lightning invoice. Let us assume the service has some data store which tracks the account balance for the user:
What is the best practice architecture to know that the account balance needs to be updated?
I know there is the waitinvoice RPC-call in c-lightning which tracks the label of an invoice (which could be a user id + some other data). Still in a live application the site should update the balance once the invoice was paid. If however the user left the side and pays the invoice it still needs to work so there needs to be some bridge from the lightning node to the data store.
In withdrawing the situation gets even more critical since withdrawing can take some time and calls can occure concurrently balance needs to be locked or widthdraw calls have to by synchronized (which I guess ist not preferable)
So what kind of architectures / best practices are you using?
Great answer. However I was more asking about the complete architecture. How to isolate / secure services? What happens if the entire service needs to run on more than one lightning node / web server / database... I will edit my question a little bit – Rene Pickhardt – 2018-10-13T18:03:07.067
1You want to split the application in a set of microservices (web, api, payment-watcher, db, etc) so you can provision and scale instances independently. – LightningK0ala – 2018-10-13T22:19:26.570
1To handle multiple lightning nodes you'll probably want a "lightning manager" service which abstracts different ln node implementations, manages connection to ln nodes, triggers withdrawals and processes incoming payments, i.e. a POST request to API should be ok, this way the update logic stays in one place and it won't matter which instance your load balancer routes you to. You can use a message broker like redis to forward updates to the relevant client. – LightningK0ala – 2018-10-13T22:20:12.107
1I recommend using Docker to compose your application and run it locally much in the same way it would be run eventually in production. Database depends on the engine you're using, whether you're sharding / replicating. You won't really need to worry about this until the app gets some serious traction - avoid premature optimisations ;) Same goes for the above really, it's better to minimise the feature set (i.e. only worry about doing it for 1 node) and gradually iterating rather than trying to do a lot at once. – LightningK0ala – 2018-10-13T22:20:25.797