code-corps / code-corps/code-corps-api
UserService might need to become an async task
- Langage dominant
- Elixir
- Étoiles
- 234
- Forks
- 82
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
# Problem
Right now, the user service does the following in a single transaction
- updates the user
- updates the associated platform customer record locally
- updates the associated platform customer record on stripe
- updates the associated connect customer records locally (can be multiple)
- updates the associated connect customer records on stripe (can be multiple)
That's a lot of work for a synchronous process. It would make sense to make it an async task.
However, this process is triggered by the user updating their profile, so we do need to update the user record itself immediately, and reply with the updated record to the client.
This means that, in order to make it an async task, we would have to lose the benefits of it being a transaction.
Taking that into consideration, we need to discuss a potential solution (if we need to change anything at all).
One option would be to add a flag to the user database indicating that the account is out of sync with the associated stripe accounts. We could then periodically retry in a background worker of some sort.
Alternatively, a more encompassing solution would be to store background tasks somewhere and retry the failed ones. Really, I'm not sure what the proper way of dealing with this in Elixir would be, compared to Rails.
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Commencez par suivre UserService depuis le point d’entrée de mise à jour du profil utilisateur jusqu’aux mises à jour locales et aux mises à jour du client Stripe décrites dans l’issue. Clarifiez d’abord si la transaction doit être remplacée et quelle approche de nouvelle tentative est privilégiée ; le travail sera considéré comme terminé lorsqu’une conception approuvée préservera la réponse immédiate à l’utilisateur tout en définissant une gestion fiable des mises à jour externes échouées.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- elixir
- Domaine
- backend, payments
- Type d'issue
- Refactorisation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 25/100