S.No | One Topic for all Mountpoints | One Topic per Mountpoint |
1. | Less load on Kafka | More load on Kafka (probably) |
2. | Less load on the Network | More load on the Network. Pls. see point (5) below |
3. | Easy administration of topic(s) | Complex administration (probably) |
4. | Effective use of the Topic | Topics are idle most of the time. Unnecessary creation of 1000's of log files wtih very minimal to no writes for most of the time |
5. | µServices can update the state of all the nodes with just one pull, may be at regular intervals, say every 5 minutes. | µServices need to pull from multiple topics with the pull count equal to the number of nodes that the µService is interested in. Given that Kafka does not support a push mechanism, µServices have to poll at regular intervals. Given that each µService will poll multiple topics, this will result in large number of socket connections, potentially resulting in over usage/exhaustion of certain resources like file descriptors. |
6. | Implementation of reading state information in µService is simpler | Implementation of reading state information in µService is relatively complex as multithreading is required to read multiple topics in parallel |
7. | Low latency to update state information | Relatively High latency to update state information as multiple reads are required |
8. | Enabling replication of topics has no impact on Kafka | Enabling replication results in 2x increase of logs in Kafka |
9. | Number of socket connections = Number of µServices | Number of socket connections increases exponentially with increase in µServices |
Overview
Content Tools