Technical Features
How the Techufy TR-369 USP Solution is built
This page is for the engineers who will run the controller. It lists what the system is made of, why we chose each part, and what that means when you operate it.
The short version: there is no single server anywhere in the design. Storage, transport and the core services are all clusters, and each can be grown separately.
Request a demo
Technical features
One rule: nothing is a single point of failure
We decided this before writing the first line. Every component below can run as more than one instance, and the system keeps working when one of them is lost. Everything else on this page follows from that rule.
Storage: Apache Cassandra
Cassandra has no primary node. Every node accepts reads and writes, data is replicated across the ring, and losing a node is routine rather than an incident. We designed the partition keys so device data spreads evenly, which is what keeps writes fast when a hundred thousand agents report in.
MQTT transport
MQTT 5.0 and 3.1.1, on either VerneMQ or Apache ActiveMQ Artemis, whichever your operations team already knows. Both run clustered, with shared storage or network replication, so a broker node can fail or be upgraded without agents noticing for long.
STOMP transport
The specification asks for STOMP 1.2; we also accept 1.0 and 1.1 because older agents exist. STOMP runs on a clustered Artemis with the same failover options as MQTT.
Core services: Apache Kafka in between
The services that parse records, apply policy, store results and raise notifications do not call each other directly. They publish to and consume from Kafka topics. A burst of traffic queues instead of failing, and a slow consumer can be scaled out without touching the rest.
REST APIs
A data API that exposes device data in a TR-181-shaped structure, and a management API for system operations. Both are documented and both are what our own web interface uses, so there is no second-class path for integrations.
Workflows: Camunda 8
Onboarding a new device model, rolling firmware out region by region, escalating a failed diagnostic: these are processes, and every operator's are different. We ship Camunda 8 integrated, so you can draw the process and run it instead of asking us for a feature.
The web interface
A React application on top of the same APIs. It handles single devices and device groups, sends Get, Set, Add, Delete, GetSupportedDM, GetSupportedProtocol and GetInstances at either level, and has dashboards and log views for both one device and the whole system. It is the tool our own support engineers use during demos and pilots.
What this buys you
Bursts queue instead of failing
Kafka absorbs the spike when a region reconnects; the services catch up without dropping messages.
Growth is a capacity change, not a migration
More devices means more Cassandra or broker nodes. The software does not change and neither do your integrations.
Upgrades without downtime
Because every component is clustered, we upgrade one node at a time. There is no maintenance window in the design.
Your systems can drive it
REST for requests, Kafka for events, Camunda for processes. Nothing you can do in the web interface is locked away from your other systems.
Where this came from
Before the USP controller we spent years on telecom billing and rating systems, which is the same problem in a different costume: a lot of small events, hard deadlines, and no tolerance for losing any of them. The choices above are the ones that worked there.
If you want to argue about any of them, write to us. The compatibility page covers which parts of the specification are implemented.