Kafka test broker

Connect

The bridge listens on port 9192 — not Kafka’s usual 9092, so a broker you already run keeps it — or the next free port, and carries each connection a client opens to the hub over one WebSocket. The hub answers as a Kafka broker, advertising the address and port the client dialed, and the bridge prints what it sees: clients, groups and their rebalances, what is produced and read.

curl -O https://sondahub.com/industrial/bridge.mjs
node bridge.mjs kafka

Kafka on localhost:9192 → wss://api.sondahub.com/kafka
bootstrap.servers=localhost:9192 — every run of the bridge is a cluster of its own
the hub is Kafka cluster TBw08p3TqOS9wY3pmh0INg, broker 1, on port 9192 — 16 topics with the last five minutes in them, store.orders.dlq for what is not an order, and any topic you create
client demo-producer connected from 127.0.0.1:53390
store.orders ← order my-order-1 for 42.5: paid in 2 s, shipped in 5, delivered in 9, each a record on store.orders keyed my-order-1
group demo: rebalancing — demo-consumer joined
group demo: generation 1, 1 member, assignor range, leader demo-consumer
fleet.telemetry → demo-consumer reads from 0@0, 1@0, 2@0, 3@0, 4@0, 5@0

node bridge.mjs kafka          # in one terminal
Kafka on localhost:9192 → wss://api.sondahub.com/kafka

node bridge.mjs kafka          # in another
Kafka on localhost:9193 (9192 was taken) → wss://api.sondahub.com/kafka

In a Kafka client

Start the bridge, then point the client at localhost:9192. Nothing else is needed: no credentials unless you want SASL, no topic to create — 16 are already talking, with 5 minutes of history in them for a consumer that starts from the earliest offset.

kcat -b localhost:9192 -L                                     # the broker and the topics
kcat -b localhost:9192 -C -t fleet.telemetry -o -3 -e         # the last three records of each partition
echo '{"id":"my-order-1","customer_id":7,"total":42.5}' | kcat -b localhost:9192 -P -t store.orders -k my-order-1
kcat -b localhost:9192 -C -t store.orders -o end -f '%k %s\n'   # and watch it get paid, shipped, delivered

from confluent_kafka import Consumer

c = Consumer({'bootstrap.servers': 'localhost:9192', 'group.id': 'demo', 'auto.offset.reset': 'earliest'})
c.subscribe(['fleet.telemetry'])
while True:
    m = c.poll(1.0)
    if m is not None and m.error() is None:
        print(m.key(), m.value())

cl, err := kgo.NewClient(
    kgo.SeedBrokers("localhost:9192"),
    kgo.ConsumerGroup("demo"),
    kgo.ConsumeTopics("bank.fx"),
)
if err != nil {
    panic(err)
}
for {
    cl.PollFetches(context.Background()).EachRecord(func(r *kgo.Record) {
        fmt.Println(string(r.Key), string(r.Value))
    })
}

bootstrap.servers=localhost:9192
security.protocol=SASL_PLAINTEXT
sasl.mechanism=SCRAM-SHA-256
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="sonda" password="sondahub";

In LockFlare Sonda: point a Kafka item at localhost:9192 with the bridge running.

Topics

The same activity the hub’s live streams carry, as keyed JSON records: each value a JSON object, each record with the headers content-type: application/json and source: sondahub, each key on the partition the Java client’s default partitioner (murmur2) would give it. Several records a second on bank.fx, more than one on fleet.telemetry, and one every few seconds on the rest.

Any other topic is yours: create it, or produce to it and let auto-creation make it with one partition. Up to 200 topics in a cluster.

Orders that move

store.orders listens. Produce an order to it — a JSON object with customer_id and a total above 0, and an id if you want to pick it — and the hub takes it through its life: paid two seconds later, shipped with a tracking number at five, delivered at nine, each a record on store.orders keyed by the order id. An order over 10,000 is cancelled instead: the payment is declined.

Anything else produced there — not JSON, not an object, no customer, no total — goes to store.orders.dlq as it came, with an error header saying why and original.topic, original.partition and original.offset saying where it was: a dead-letter topic to point a consumer at.

key my-order-1  {"id":"my-order-1","customer_id":7,"total":42.5}
key my-order-1  {"id":"my-order-1","number":"SO-my-order-1","customer_id":7,"total":42.5,"status":"paid","previous":"pending"}
key my-order-1  {"id":"my-order-1","number":"SO-my-order-1","customer_id":7,"total":42.5,"status":"shipped","previous":"paid","tracking_number":"1Z…"}
key my-order-1  {"id":"my-order-1","number":"SO-my-order-1","customer_id":7,"total":42.5,"status":"delivered","previous":"shipped"}

Consumer groups

The classic group protocol, as a broker runs it: the first member waits 500 ms for others before the group’s first generation; a new member makes everyone rejoin, and heartbeats say so with REBALANCE_IN_PROGRESS; the leader computes the assignment with whatever assignor the members share — range, round robin, sticky, cooperative-sticky, your own — and the broker hands it out; a member that stops heartbeating is dropped when its session times out (6,000 ms to 1,800,000 ms). Committed offsets last as long as the cluster. Start two consumers in one group and watch the partitions split between them in the bridge’s log.

SASL

Optional, on the same port: a client configured for SASL_PLAINTEXT signs in with PLAIN, SCRAM-SHA-256, SCRAM-SHA-512; one configured for PLAINTEXT just connects.

What the broker answers

The APIs and versions it lists in ApiVersions. Versions from the first flexible one on use the compact encodings and tagged fields. Produce is listed from v0, as Apache Kafka 4 lists it, but answered from v3, the first with record batches.

Configurations and limits

A cluster keeps up to 24 MB of records; past that the oldest batches go, and the log start offset moves, so a consumer that asks for an offset that is gone gets OFFSET_OUT_OF_RANGE and its reset policy decides. Requests up to 8 MB, record batches up to 1,048,588 bytes (max.message.bytes), 64 partitions a topic. Batches compressed with gzip, snappy and lz4 are opened (so an order compressed any of those ways is taken); zstd batches are kept and served as they came, but not opened.

JSON, from any WebSocket client

A text message to wss://api.sondahub.com/kafka is a request: list the topics, subscribe to records as they land (with what the topics already hold first, if you ask), or produce one. Values and keys come back as JSON when they are, as text when they are not, and in base64 when they are neither.

{"topics":true}
{"subscribe":"fleet.telemetry"}
{"subscribe":["store.orders","store.orders.dlq"],"from":"earliest"}
{"produce":"store.orders","key":"my-order-2","value":{"customer_id":7,"total":19.9}}
{"unsubscribe":"*"}

{"topic":"bank.fx","partition":1,"offset":193,"timestamp":"2026-10-07T23:14:45.261Z","key":"USD/AUD",
 "value":{"pair":"USD/AUD","base":"USD","quote":"AUD","rate":1.5255,"bid":1.5243,"ask":1.5267,"change_pct":0.36},
 "headers":{"content-type":"application/json","source":"sondahub"}}

The bridge, on the wire

For anyone writing a bridge of their own: it opens wss://api.sondahub.com/kafka with the subprotocol kafka and says hello in text — {"bridge":"kafka","version":1,"port":9192}, the port it listens on, which the broker advertises. Then every client connection rides the WebSocket under an id the bridge gives it: a byte for what happened (3 bytes of the stream, 4 a connection opened, 5 one closed), the id (four bytes, big-endian), two zero bytes, then for a 3 the bytes as they came off the socket, and for a 4 {"peer":"ip:port","local":"ip:port"} in UTF-8 — who dialed and the address they dialed. The hub sends 3 and 5 back, and {"log":…} lines in text.

Also on sondahub

Fake REST API · Public GraphQL API · gRPC-Web & Connect · SOAP test server · JSON-RPC & XML-RPC · OData test server · FHIR test server · Socket.IO test server · WebSocket test server · SSE test server · Public MQTT broker · MCP test server · MCP OAuth test server · Writes that persist · OpenAPI mock server · Webhook tester · Chaos and rate limits · SAML test IdP and SP · SCIM 2.0 test server · OAuth 2.0 test server · Auth test endpoints · HTTP test endpoints · Fake JSON data · Stripe sandbox · Twilio sandbox · SendGrid sandbox · Authorize.net sandbox · OpenAI sandbox · Anthropic sandbox · AWS Secrets Manager sandbox · Azure Key Vault sandbox · Google Secret Manager sandbox · 1Password Connect sandbox · Doppler sandbox · Infisical sandbox · OPC UA test server · Modbus TCP simulator · HART-IP simulator · DDS simulator

The mock APIs themselves: fake e-commerce API, fake IoT API, fake banking API, fake social media API, fake helpdesk API, fake flight booking API, fake user directory API. Built as the playground for LockFlare Sonda, the API client that lives on your computer.