Quand Kafka devient progressivement le « système nerveux central pour les données », la simplicité des brokers peut passer d'une bénédiction à une malédiction. Les services qui étaient auparavant découplés doivent de plus en plus se connaître les uns les autres pour éviter les problèmes de collisions: topic, consumer groups, schema, connecteurs, métadonnées etc.

Chez Conduktor, nous avons eu le défi d'accueillir des milliers de tenants Kafka performants et isolés.

Pour trouver une solution viable et économique, nous avons exploré un large éventail de solutions possibles, notamment :

• Plus de clusters Kafka - Chaque nouveau service peut-il avoir son propre cluster?
• Convention - Choisissez des prefix, des headers, etc. pour éviter les conflits
• Application côté client - Personnaliser les clients pour garantir la compatibilité
• Application côté serveur - Configurez les brokers pour n'autoriser que les clients qui se comportent correctement
• Proxy - Un outil efficace

Embarquez avec nous dans un voyage d'idées, de leçons et de solutions sur la façon dont nous avons résolu le multi-tenancy et comment vous pouvez l'appliquer à presque tous les déploiements Kafka.