kafka-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gwen Shapira <g...@confluent.io>
Subject Re: mapping events to topics
Date Wed, 07 Oct 2015 00:39:31 GMT
I usually approach this questions by looking at possible consumers.

You usually want each consumer to read from relatively few topics, use most
of the messages it receives and have fairly cohesive logic for using these
messages.

Signs that things went wrong with too few topics:
* Consumers that throw away 90% of the messages on topics they read
* Consumers with gigantic switch statements for handling all the different
message types they get

Signs that you have too many topics:
* Every consumer needs to read messages from 20 different topics in order
to construct the objects it actually uses

If you ever did data modeling for a datawarehouse, this will look a bit
familiar :)

Gwen

On Tue, Oct 6, 2015 at 4:46 PM, Mark Drago <markdrago@gmail.com> wrote:

> Hello,
>
> At my organization we are already using kafka in a few areas, but  we're
> looking to expand our use and we're struggling with how best to distribute
> our events on to topics.
>
> We have on the order of 30 different kinds of events that we'd like to
> distribute via kafka.  We have one or two consumers that have a need to
> consume many of these types of events (~20 out of the 30) and we have other
> consumers that are only interested in one type of event.
>
> We're trying to decide between a model where we have one topic containing
> many kinds of events or a model where we have many topics each containing
> one type of event.  We have also thought about mixed models where we have
> one large topic that we later break down in to smaller ones or we have many
> small topics that we later coming in to a large topic.
>
> I'm curious to hear about best practices and past experiences from the
> members of this group.  What is the general best practice for reusing
> topics or creating new ones?  What has worked well in the past?  What
> should we be considering while making this decision?
>
> Thanks in advance!
> Mark.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message