Stripe ne veut qu’un seul chiffre

• exe, au lieu d’appeler directement l’API de paiement à travers toute la logique produit, enregistre les changements d’état comme des faits facturables (billable facts) et rapproche l’état confirmé avec Stripe
• Dans l’ancienne architecture, les transactions de base de données et les appels à l’API de paiement étaient entremêlés, si bien que des exceptions comme les échecs partiels, les états d’abonnement anormaux ou les refus de paiement perturbaient jusqu’aux flux produit
• Lorsqu’un siège est ajouté à une équipe, l’état est marqué comme dirty, puis un worker ultérieur calcule la quantité selon les règles métier et ne met à jour la quantité de l’abonnement Stripe que si elle a changé
• En découplant le paiement, l’onboarding des nouveaux membres d’une équipe ne dépend plus du code de paiement, et modifier les règles de calcul des sièges n’affecte pas les flux d’invitation et d’inscription
• La même structure de rapprochement est appliquée à la facturation à l’usage, comme les VM actives et l’utilisation du disque, ainsi qu’aux achats intégrés iOS, ce qui permet de conserver les événements produit tout en ne changeant que l’intégration propre à chaque fournisseur de paiement

---

Séparer la logique de paiement des flux produit

• Quand la logique de paiement se mêle à la logique métier générale, le code associé se répand dans tous les chemins critiques nécessitant une facturation, et la structure tarifaire devient elle aussi fragile et difficile à modifier
• exe vise à éviter qu’une seule personne détienne tout le savoir sur le paiement, afin que chacun puisse modifier le code concerné, tout en confiant les exceptions complexes à un spécialiste
• Au départ, la facturation des sièges d’équipe regroupait tout, de l’acceptation d’une invitation jusqu’au paiement, en un seul grand flux
  • L’utilisateur accepte l’invitation, vérifie son compte, puis rejoint l’équipe
  • Il reçoit les droits d’accès aux VM partagées et les ressources de calcul correspondant au forfait
  • L’API de paiement est également appelée au cours de ce processus
• Combiner ainsi les modifications de base de données et les appels à une API externe peut provoquer des échecs partiels, où un seul des deux côtés réussit
  • L’état de l’abonnement de l’équipe peut devenir anormal
  • Le paiement du siège supplémentaire peut être refusé
  • Plus les exceptions s’accumulent, plus l’ensemble de l’architecture devient fragile

Faits facturables et rapprochement a posteriori

• Un fait facturable est une opération atomique indiquant qu’un état donné a changé
  • On exécute d’abord la logique produit pour confirmer le nouvel état de la ressource
  • Ensuite, on rapproche l’état du fournisseur de paiement à partir du fait confirmé
  • Stripe n’a besoin que de la quantité finale, pas du processus ayant mené à cet état

• Rapprochement des sièges d’équipe

  • Lorsqu’une invitation est acceptée, l’état des sièges de l’équipe est marqué comme dirty
  • Un worker ultérieur détecte cet état dirty et calcule les variations de sièges selon les règles métier
  • Ce n’est que si la quantité a changé que la quantité de l’abonnement Stripe est mise à jour
  • Comme l’ajout de membres et le code de paiement sont séparés, réécrire le flux d’invitation ne casse pas la facturation, et la méthode de calcul des sièges peut aussi être modifiée indépendamment

• Facturation à l’usage et achats intégrés

  • Le même processus de rapprochement s’applique à toute facturation à l’usage
    • Le système enregistre les faits relatifs aux VM actives et à l’utilisation du disque
    • Un worker de comptage les rapproche avec l’état du fournisseur de paiement
    • Même si l’on ajoute un nouveau mode de facturation, les faits restent inchangés ; seule la manière de les rapprocher avec chaque API change
  • L’app iOS transmet elle aussi uniquement le fait qu’une personne s’est abonnée via un achat intégré, puis l’état réel du paiement est rapproché ensuite
  • L’architecture de paiement est devenue un domaine que d’autres membres peuvent également manipuler, et les changements de fonctionnalités produit, comme le flux d’invitation, risquent moins d’endommager le système de facturation

[GN⁺]

Commentaires sur Lobste.rs

• L’idée centrale de l’article — détecter et traiter les changements de manière asynchrone — est efficace pour réduire le couplage et implémenter des effets de bord.
  Mais les LLM sont des outils qui accélèrent la dispersion du code un peu partout plutôt que de l’empêcher, ce qui peut facilement devenir une dette architecturale. Je me demande aussi comment on peut relire du code généré plus vite qu’on ne peut le comprendre ; le passage indiquant qu’Exe ne fait même pas de revue de code est encore plus inquiétant.

  • Il faut se rappeler que le secteur tech, qui n’a jamais vraiment été très sérieux, traverse aujourd’hui une période particulièrement peu sérieuse.
  • Pour quelqu’un qui travaille sur des systèmes de facturation, c’est une approche assez effrayante. Une plateforme de facturation se compose de plusieurs contextes aux frontières bien définies, et les LLM respectent mal les frontières de domaine, ce qui risque de causer beaucoup de souffrance.
  • Je me suis dit que ce n’était pas « même avec des LLM », mais « surtout avec des LLM » que le code se disperserait davantage.
  • À ma connaissance, cette citation n’est pas d’Orwell mais d’Upton Sinclair.

• Cette architecture est intéressante, mais on ne voit pas clairement comment elle résout le problème présenté au début de l’article. Si un paiement est refusé, il semble qu’on fournira d’abord les ressources impayées plutôt que de garantir le paiement de toutes les ressources.
  Un worker de facturation pourrait publier le fait que le paiement est declined afin de récupérer les ressources, mais cela devient une structure circulaire par rapport à un flux unidirectionnel propre. Cela peut bien convenir à un service de calcul facturé mensuellement comme Exe, mais c’est un compromis difficile à accepter pour une entreprise qui expédie du matériel physique ou revend des sièges d’un autre service.

  • Il s’agit d’un modèle de facturation centré sur le logiciel, où le produit est abstrait et substituable. La facturation à l’usage repose sur des données analytiques indiquant qu’un événement facturable s’est produit, et il est préférable que le système de facturation les agrège pour produire des lignes de facturation cohérentes. Comme les événements facturables peuvent provenir de plusieurs endroits, les sortir du code produit est aussi une approche saine.
    Cela ne répond toutefois pas directement à la gestion des échecs d’appels API ou de transactions de base de données, des états d’abonnement anormaux, ni des refus de paiement de sièges. Les problèmes restent aussi les mêmes si un refactoring casse la collecte analytique, si une ligne donnée n’est plus marquée comme modifiée, ou si un nouveau chemin oublie de marquer le changement.
    Cela ne résout pas non plus l’état lié à la facturation qui existe à l’intérieur du produit, comme les limites de sièges ou de quotas gratuits, les plafonds de dépense et la déduction d’un solde prépayé. Le service produit peut publier des événements et le service de facturation peut répercuter l’état de conformité vers le produit, mais on se retrouve alors avec deux acteurs dans un système distribué avec état.

• Stripe semble ne vouloir qu’un seul chiffre, mais à une certaine échelle, fournir aussi les détails des lignes de paiement peut réduire les frais d’interchange et augmenter le taux d’autorisation.

• La façon dont Exe ne fait pas de revue de code est originale. Je serais curieux de savoir comment ils gèrent alors les releases et les tests.