title: Sharing partitioning logic across polyglot producers with Kafka
body: <p>We are building an event sourced system at my company, relying on Kafka.</p>
  
  <p>In order to be GDPR compliant, we need to be able to update the events.</p>
  
  <p>Our idea is to use the compaction and tombstone capabilities.</p>
  
  <p>This means that we cannot use the default partitioning strategy, as we want each message to have an unique key (in order to overwrite a specific message), but we still want events occuring on the same aggregate to end on the same partition.</p>
  
  <p>Which brings us to the creation of a custom partitioner (basically copying the "hash modulo" logic of the default partitioner, but using a different value than the message key to compute the hash).</p>
  
  <p>The issue is that we're evolving in a polyglot environment (we have php, python and Java/Kotlin services publishing and consuming events).</p>
  
  <p>We want to ensure that all these services will produce messages to the same partition given a specific partition key (in case different services will publish events to the same topic).</p>
  
  <p>Our main idea was to use a common hashing algorithm, but we find it hard to find one with both a strong distribution guarantee and a good stability (not just part of an experimental lib).</p>
  
  <p>PHP natively supports a wide range of <a href="http://php.net/hash_algos#example-924" rel="nofollow noreferrer">hashing algorithms</a>, but we find it hard to find the same support in the other languages.</p>
  
  <p>As Kafka default partitioner relies on murmur2, we started looking in that direction as well. Unfortunately, it is not natively supported by php (although some <a href="https://github.com/7snovic/php_murmurhash" rel="nofollow noreferrer">implementations</a> exist). Furthermore, this algorithm uses a seed, which means that we will need to use the exact same seed for all our publisher services, which is starting to make the approach look quite complex.</p>
  
  <p>However, we could be looking at the design from the wrong angle. Sharing event store write capabilities across polyglot services might not be a good idea and each services could have its own partitioning logic as long as it ensures the "one partition per aggregate" requirement. The thing is that we have to think this ahead, because no technical safeguard will prevent one service in the future to publish on a "shared" event stream (and not using the exact same partitioning logic will have a huge impact when it happens).</p>
  
  <p>Would someone has experience with building an event store with Kafka in a polyglot environment, and could highlight us on this specific topic, please?</p>