Comment trancher entre un service de notifications unique et des microservices?

[JoshuaD]

Salut à tous, je suis un peu dans le flou sur une décision d’architecture. Je refactorise un module de notification et je me demande si je devrais tout centraliser dans un service unique, ou si garder des petits services spécialisés par type d’envoi (mail, SMS, push) est plus malin, même si ça éparpille un peu la logique. J’ai peur que le service unique devienne un monstre difficile à maintenir, mais en même temps, la duplication me dérange. Vous avez déjà eu ce genre de dilemme sur la façon de structurer vos services ?

[Charles.H]

Pour cette question de centraliser ou non, on parle vraiment de la notification comme d’un service. Un cœur unique peut réduire les duplications mais devient un monstre si on empile les cas d’usage. Je verrais bien une façade orchestrant des handlers dédiés par type d’envoi et une couche d’abstraction qui expose les mêmes contrats sans lier le cœur à la logique métier.

[Robert51]

J’ai vécu ce dilemme sur un gros produit lié à la notification. J’ai commencé par des services séparés (mail, SMS, push) et, avec un orchestrateur léger, on garde la flexibilité sans tout mélanger. Résultat, testabilité et évolutivité améliorées, et la duplication a moins explosé que prévu.

[RyanAP]

Centre unique, c’est tentant, mais ça peut devenir fragile si on ne découpe pas bien les responsabilités. Pour la notification, un seul service qui connaît tout, c’est souvent le point faible d’un système qui croit être simple.

[Justin_D]

Est-ce que tu cherches surtout à éviter un cadre trop rigide ou à gagner en flexibilité pour tester de nouveaux canaux de notification ?

[EthanH]

Si j’ai bien compris, tu veux conserver une modularité dans les envois tout en évitant une multiplication d’API et de branchements trop lourds dans le code de base de la notification.

[Abigail.T]

Un autre angle est la documentation des contrats d’envoi et les attentes des lecteurs internes: les équipes réagissent plus positivement quand le flux de la notification est clair et que la tolérance à l’échec est explicite, sans que tout soit décrit comme un chemin unique.