![\"Python](\"/assets/images/decimal-places-5-23.png\")
I was reviewing a helper in my codebase. It counts decimal places of an\namount. Here it is.
\ndef _decimal_places(value: float) -> int:\n try:\n decimal_value = Decimal(str(value)).normalize()\n except (InvalidOperation, ValueError):\n return 0\n\n exponent = decimal_value.as_tuple().exponent\n return max(0, min(6, -exponent))To understand how it works, I studied the helper in a Python REPL. 5.23 came back as 2.\n5 and 5.0 both came back as 0.
str(value) hands the float to Decimal.\nThen .normalize() strips trailing zeros, and .as_tuple() breaks what is\nleft into sign, digits, and exponent. The helper negates the exponent and\nclamps the result between 0 and 6. The normalize is why 5 and 5.0 agree.
Then I passed float('inf').
![\"Python](\"/assets/images/decimal-places-infinity.png\")
Decimal('Infinity') parses fine. The exponent came\nback as 'F'. A string. One line later the helper ran -exponent on it, and\nPython raised TypeError: bad operand type for unary -: 'str'.
So I went back and looked at the guard. The try/except wraps the construction\nonly. A garbage string dies in there with InvalidOperation, and the helper\nreturns 0. The guard caught the parse and missed the crash.
NaN is stranger. Its exponent is 'n', and its digits tuple is empty. It\nreaches the return line too.
My fix checks the type at the crash site.
\n exponent = decimal_value.as_tuple().exponent\n if not isinstance(exponent, int):\n # NaN / Infinity have no decimal places\n return 0\n return max(0, min(6, -exponent))The helper returns 0, the same answer bad input already gets.
" }, { "id": "https://ssupawat.github.io/posts/mqtt-one-topic-many-consumers/", "url": "https://ssupawat.github.io/posts/mqtt-one-topic-many-consumers/", "title": "Two ways to split one MQTT topic across consumers", "language": "en", "date_published": "2026-09-12", "summary": "MQTT hands every subscriber a copy of every message. Two ways around it: partition the topic at the publisher, or use an MQTT v5 shared subscription. Where the decision lives is the whole difference.", "content_html": "MQTT fans a topic out. Every client subscribed to it gets a copy of every\nmessage. That is the point of the protocol, and most of the time it is what I\nwant too.
\nIt is not what I wanted here. I had a Kafka consumer group in mind: several\nconsumers on one topic, the messages split between them, each one handled once.\nI went looking for how to do that in MQTT.
\nThe short answer is no on v3.1.1, which is what I was on. There is no consumer\ngroup in the protocol. So the question turned into what to do\ninstead, and I found two answers and built both, in\nmqtt-client-load-balancing,\none on a branch each.
\nThe first way needs nothing from the broker. It uses the topic hierarchy as the\npartition key.
\nI picked three partitions. My publisher appends a partition number to the topic\non every message, chosen at random. Each consumer then subscribes to a single\npartition. Every message still goes to exactly one subscriber, because no two\nof them subscribe to the same topic.
\ndemoTopic/partition2 reaches consumer2 because it is the only client subscribed to it.This is roughly how Kafka partitions a topic. The difference is that in Kafka\nthe partition count is a property of the topic, held in one place. Here it is a\nconvention, and every publisher has to know it.
\nThat is what makes the approach expensive. The partition count is baked into my\npublishers, so the consumer count is too. I need one consumer per partition,\nand the two counts move together. Scaling out is not a consumer-side change.\nTo go from three partitions to six, every device that publishes to the topic\nhas to start using the new range. On a fleet of devices in the field, that is\na rollout.
\nMQTT v5 has the same thing as a protocol feature. From\nHiveMQ:
\n\n\nIn a standard MQTT subscription, each subscribing client is privy to a copy\nof each message broadcasted to that topic. With shared subscriptions, clients\nsharing a subscription in the same group receive messages in rotation, a\nprocess sometimes referred to as client load balancing. The message load of a\nsingle topic is distributed across all subscribers.
\n
It is a prefix on the subscription:
\n$share/<group>/topic\n$share marks it as shared, <group> names the group, and the rest is the\ntopic I want. Consumers that give the same group and the same topic form one\ngroup. The broker delivers each message to one member of it.
Which member is the broker's business. The spec does not name an algorithm.\nMosquitto, which the demo runs on, goes round-robin. So the delivery is a\nrotation. A consumer that is still busy gets its turn anyway.
\nA group does not change what anyone outside it sees. The demo keeps a couple of\nsubscribers on plain demoTopic to show it: they go on receiving every\nmessage, while the three in the group split their own copy between them.
$share/shared-subscriber-group/demoTopic and split the stream. The plain sub holds demoTopic with no prefix and still gets all of it. The publisher is unchanged either way. It publishes to plain demoTopic, because $share is a subscribe-side prefix.Scaling out is now what I wanted. I start another consumer, give it the same\ngroup, and the broker starts including it in the rotation. Nothing on the\npublishing side changes, because it never knew how many consumers there were.
\nThe cost is a version floor. Shared subscriptions are v5. The prefix lives on\nthe subscribe side, so the consumers and the broker have to speak it.\nPublishers are not in the way. That sounds like a small bill until someone asks\nwho is holding the versions.
\nBoth approaches split the same stream. The difference is where the split is\ndecided.
\nPartitioning puts the decision in every publisher. The topology is then spread\nacross the fleet, and changing it means changing all of it. A shared\nsubscription puts the decision in the broker, and the publishers never learn\nabout it. That is why the consumer side can be resized on its own.
\nSo MQTT has no consumer group on v3.1.1, and something close to one on v5.\nThat is the answer to the question I started with.
\nWe never took it. v5 was out by then, but our devices had already shipped on\nv3.1.1. The broker was not moving either. I no longer remember why. The devices\non their own would not have stopped us, since a publisher never sees the\nprefix. The broker did.
\nSo the shared subscription stayed a branch in this repository. Partitioning was\nthe only one of the two I could actually have used, at the price above: every\npublisher in on the scheme, and a rollout to the fleet to change it.
\nBoth branches run under Docker Compose, and the consumer logs show the split:\ngithub.com/ssupawat/mqtt-client-load-balancing
\nI got a chance to serve an AG-UI endpoint. I started\nwhere the protocol points. AG-UI's\nLangGraph integration\nships a helper that registers the endpoint. It calls @app.post(path) and\nreturns a StreamingResponse. From there I wired it into my backend, and it\nran.
Then I started losing streams. About two minutes into a run, the stream would\nstop. After that the client sat with half an answer.
\nMy first guess was an idle timeout. Something in front was hanging up on a\nstream that had gone quiet. The standard fix for that is a keepalive, because\nit stops the connection from looking idle. So I added one. Even so, I still\nlost the stream at two minutes.
\nSo whatever sits in front counts the age of the connection. It hangs up at two\nminutes, whether or not bytes are moving. Next I asked the infra team to raise\nthe limit, and they turned me down. In the end I never did learn which layer\nsets that number.
\nThat settled the shape of the problem. From then on, every run longer than two\nminutes gets cut. And I have to survive it from my side.
\nNormally the browser would reconnect for me. EventSource does it for free.\nFirst it retries on its own. Then it sends back a Last-Event-ID header. That\nheader names the last event the client saw. Then the server carries on from\nthere. But I could not use any of it. That machinery is GET only, and AG-UI\nanswers on POST. That puts me on fetch and a ReadableStream. Those will\nstream a response. Even so, recovering one is my job.
The second wall came right behind the first. My endpoint runs on several pods.\nBecause of that, the retry goes through the load balancer. It lands\nwherever it lands. If the half-finished run lives in the process that started\nit, only that process can answer. Then I am back to pinning traffic with\nsticky sessions.
\nSo I needed two things. First, the work has to keep going after the client is\ngone. Second, any pod has to be able to read a record of it.
\nI built reconnectable-sse to\ntry it out. My production endpoint is Python. But this was a concept, and the\nlanguage was free. So I used it as an excuse to get familiar with Go. In the\nend the shape is the part that matters.
\nIt comes down to two lines:
\nif !streamExists(r.Context(), key) {\n go runEventGenerator(streamID, string(body))\n}\n\nrunSSEResponse(r.Context(), streamID, lastEventID, w, flusher)I give runSSEResponse the request context. A disconnect stops it. That is\nwhat I want, since there is nobody left to write to. Meanwhile\nrunEventGenerator gets context.Background(), and it keeps running. Hand it\nthe request context instead, and the disconnect kills the work itself. Then\nnothing is left to come back to. The run also has to finish and write its\nhistory to the database. Whether anyone is still watching is beside the point.
context.Background(). It keeps going through the drop and the reconnect, even though api-2 is the one talking to the client now.Resume then came down to an offset. Redis returns an entry id on every XADD.\nThat id goes out as the SSE id. Then the client sends it back on the retry.\nFrom there it goes into XREAD as the starting point. That leaves no cursor\ntable and no bookkeeping. In the end the id the client is holding is the\noffset.
I ran it. It does what I wanted. After a drop mid-stream, a client comes back\nthrough a different pod and picks up where it stopped.
\nStill, I left edges in it. The generator starts under a check-then-act. So two\nconcurrent first requests with the same stream id can both start one.
\nDesign, endpoints, and how to run it: github.com/ssupawat/reconnectable-sse
" } ] }