Memphis uses a modified version of NATS at its core, which receives, stores, and sends the data in a binary format for efficient memory allocations, formal alignment, and performance. The NATS streaming protocol is built on the NATS protocol and makes use of Google’s Protocol Buffers. These Protocol Buffer messages are collected as bytes and then published to a specific station as Memphis messages. The Memphis broker is also a fork of NATS.io, an existing and battle-tested messaging queue with a few tweaks and improvements. 

The architecture also uses the HTTP protocol to produce messages for various use cases. An HTTP proxy receives messages via HTTP and produces those messages to the respective station in the form of a TCP-based client. Common use cases produce events directly from a frontend, user session, browser, or data received via third-party apps.

The way HTTP works is that an HTTP request is created by an endpoint and directed towards the HTTP proxy over port 4444. The proxy then receives the incoming request and sends it to the station in the form of a message. To make scaling possible, the HTTP Proxy is separate from the brokers’ pod and scales individually. 

Support for other protocols, including WebSockets, gRPC, MQTT, and WASM will be added soon.