Real-time telemetry from instrument to browser
Designed and built the message-processing subsystem that streams live instrument data from RabbitMQ to the browser without swamping the client.
The problem. The manufacturing instrument produces a steady stream of high-frequency sensor and state data, and operators need to see it live in a web application without swamping the browser.
What I did. I designed and built the message-processing subsystem end to end, with consumers reading from RabbitMQ, a throttled publisher, hosted-service workers, per-message-type processors, and the SignalR fan-out to connected clients, along with the unit tests. Later I added runtime caching and automatic reconnection, so that a client that dropped could catch back up cleanly.
What happened. It became the real-time backbone of the application, and I wrote every file in the subsystem and about 68% of the commits that touched it.
What I'd tell someone else. Throttle on the server. The browser doesn't need every message, it needs the latest state, often enough to look live, and pushing every event straight through is the easy way to build something that works in a demo with one instrument and then falls over in production.