Quand nous évoquons que l’architecture d’un SI repose sur Kafka ou Redis, sommes-nous vraiment en train de parler architecture ? Ne parlons-nous pas plutôt de design (ou d’implémentation) ? Cela nous est tous arrivés d’avoir la présentation d’une architecture qui ressemble à ceci : Ce qui est intéressant est la considération différente entre le service applicatif, NginX et Apache Kafka. Pourquoi, pour le service, n’avons-nous pas le framework et le langage utilisé ?

Dans un précédent article, je parlais de l’utilisation d’un timeout sur les appels externes. Reprenons le dernier schéma : Le composant A abandonne l’appel vers B au bout de 80ms. Il doit maintenant répondre à son client. La meilleure réponse devrait être la vérité, c’est à dire retourner que le système rencontre un ralentissement. Au client de gérer cette erreur. Dans certains cas, il est acceptable (voire préférable) de retourner un résultat qui peut être :

Quand on parle de système distribué, le terme « disponibilité » revient souvent. Et souvent, on associe la disponibilité à la scalabilité horizontale. Comme s’il suffisait de multiplier les instances d’un service pour avoir un système disponible. Avant de continuer, définissons ce qu’est la disponibilité. Un système est disponible s’il répond ET s’il répond dans les temps. Pouvons nous considérer un système comme disponible si son temps de réponse est supérieur à 5 secondes alors qu’il est normalement de 30 ms ?