Apache Kafka & Memphis.dev
Published: 2022-05-31 13:30:40

## **What is Memphis.dev, what is Apache Kafka, and what are the strength and weaknesses of each framework**


![memphis vs kafka](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xbvzowdkofftp2byoyts.png)

Let’s start!

The complete comparison table is at the bottom.

**What is [Memphis.dev](https://memphis.dev)?**

A distributed message broker designed and constructed to make developers’ lives who work around event-driven software incredibly easier with event-level observability and troubleshooting tools. [memphis.dev](https://memphis.dev) started as a fork of [nats.io](https://nats.io) project (since 2011), written in GoLang, and creating its own stream on top.

Memphis.dev uses the same paradigm as Apache Kafka of produce-consume.

**Memphis.dev Important objects**

1. Broker
2. Factories
3. [Stations](https://docs.memphis.dev/memphis-new/dashboard-ui/stations)
4. Producers
5. Consumers / Consumer groups
6. UI
7. CLI
8. Kubernetes


![Memphis.dev Architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tj7y22q2vrgkgvu111en.png)


**Memphis.dev flow**

Memphis robust version deployed over Kubernetes using helm chart.

With Memphis deployment, also deployed is the UI, which provides the user with complete control over the entire Memphis cluster.

Compared to other terminologies like topics and queues, Memphis has stations that are grouped under factories.

Apps produce (write) and consume (read) data to and from stations.

To scale the performance and redundancy of consumers in a super easy manner, several consumers of the same kind can be grouped within the same consumer group.

Messages remain in the station until they hit the defined retention (defined at station creation), but will be consumed exactly once by the same consumer group.


![Memphis.dev message ordering](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rfjdpx4d9t320d4h0aht.png)


**Persistency (Where data is being saved)**

- Memory — Higher performance, higher cost, redundant for up to two failed brokers.
- File — Lower performance, lower cost, redundant for an entire cluster breakdown.

Both are replicated across the brokers as defined by the user.


![Memphis.dev persistence mechanism](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kwzyjxgu3uoxm9n7cbw0.png)


**Redundancy / HA**

- Cluster-mode — Made by multiple brokers (min. 3). Data is replicated across brokers. Redundant across AZs.
- Standalone — Made by a single broker.

---

**What is Apache Kafka?**

Apache Kafka is a distributed event store and stream-processing platform. It is an open-source system developed by the Apache Software Foundation written in Java and Scala. Well-known and 2nd most popular event store in the world after RabbitMQ.


**Apache Kafka Important players**

1. Consumer / Consumer groups

2. Producer

3. Kafka connect

5. Topic and topic partition

6. Kafka streams

7. Broker

8. Zookeeper (Will be moved soon)



**Apache Kafka flow**

Apache Kafka is one of the most mature message brokers in the market.

Producers send a message record to a topic. A topic is a category or feed name to which records are published. Consumers subscribe to a topic and pull messages from it.

In Kafka, messages remain in the topic, also if they were consumed (limit time is defined by retention policy)

Heavy memory consumer for performance.


![apache kafka](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/30wkpfi9q46a8gu9wvl2.png)


**Persistency (Where data is being saved)**

- Memory
- File (log files)


**Redundancy / HA**

Kafka does it by using Zookeeper to manage the state of the cluster.

In [version 3.3](https://cwiki.apache.org/confluence/display/KAFKA/KIP-833%3A+Mark+KRaft+as+Production+Ready), KRaft will be available for production use and remove the need for Zookeeper.


![kafka ecosystem](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lx626ww0rasr0jo9afms.jpeg)

---

**Bottom line**

Apache Kafka has a strong maturity and large community, as well as battle-tested against large workloads and distributed environments, but it comprises multiple technical challenges in both ops, developer onboarding, troubleshooting, and cost.

Memphis.dev has a much smaller (yet a growing) community, and less documentation, but eliminates almost completely the need for operations and tunings, developers can onboard autonomously, run on any Kubernetes, and comes with observability and troubleshooting features that make it loveable by devs who are starting their way through the forests of event-driven and real-time.

---

**Comparison Table**

![comperison](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i1lod3d0avtjqls3pwpk.png)


![memphis vs kafka](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7wlnogllt73tn8iewdt5.jpeg)


Thanks for reading!