Broker server contains logical partitions called topics where producers can publish content to and consumers can consume content from. Producers and consumers establish a raw TCP connection to the broker server, therefore it is a bidirectional communication. ![[producer-broker-flow.png]] * Producer: publish content to specific broker topics. Above, content is being published to the Users topic. * content is appended to specific topic (you can only append content, not delete). * each message is referred to by the topic it was placed in and the position index it was placed inside the topic. This makes retrievals very fast. ![[consumer-broker-flow.png]] * Consumer: Consume content from specific broker topics. * consumers consume messages from position 0...n. The consumer pulls the broker server topic it is interested in. It is not a push model where the broker server pushes content to the consumers. ## Kafka Topic Partitions (Equivalent of Database Sharding) Partitions introduce complexity for producers and consumers. Previously, they only needed to know the topic they wished to write content to or consume content from. Now they also need to know what partition they need to write and read content from on top of the topic. * This process is fast because as shown below, we are always working with indexes and partitions. * The position in the partition where the message is placed is returned to the producer. ![[producer-consumer-boker-partitions-flow.png]]