Telecom & Media
Telecom systems fail differently from most software. The volumes are high enough that a fractional error rate is a material sum of money, and the events keep arriving whether or not your pipeline is healthy.
At this volume, small errors are expensive
A rating rule that is wrong in one case per hundred thousand is a rounding error in a test suite and a regulatory problem at production volume. The same arithmetic applies to duplicate event processing, to timestamps that drift between network elements, and to any reconciliation that runs monthly rather than continuously.
So the engineering emphasis sits on idempotency, ordering and reconciliation rather than on features. Every event needs an identity that makes reprocessing safe, and the pipeline needs to reconcile against source counts often enough that a discrepancy is a small correction instead of a restatement.
Where we work
Mediation and rating
Usage collection and charging where duplicate or out-of-order records are routine and must not become billing errors.
Billing and revenue assurance
Reconciliation between network usage, rated events and invoices, designed to surface leakage continuously.
OSS/BSS integration
Connecting provisioning, inventory and customer systems that were each built to be the system of record.
Network data and observability
High-volume telemetry pipelines where retention cost and query latency are the design drivers.
Streaming and content delivery
Delivery, DRM and playback analytics, where quality of experience matters more than aggregate bandwidth.
Customer platforms
Self-service, activation and support tooling that reflects network state accurately enough to reduce calls.
Constraints that shape the work
Volume turns rounding into money
A one per cent error in rating is not a bug report, it is a revenue assurance incident. Correctness at the record level is the whole job.
Pipelines must survive being behind
Backlogs happen. The system has to catch up without double-counting, reordering, or dropping records — and that has to be tested by deliberately falling behind.
OSS and BSS speak different languages
Provisioning and billing disagree about what a customer has. Reconciliation between them is continuous work, not a migration task.
Retention is regulated and expensive
How long records are kept, and in what form, is set by law and by storage cost. Both push in opposite directions and the design has to hold the line.
Pipelines that survive being behind
A streaming pipeline's real test is not steady state; it is recovery. When a consumer has been down for two hours, the backlog arrives compressed, out of order, and alongside current traffic. Systems designed only for the steady case fall further behind at exactly the moment they need to catch up.
That means back pressure rather than unbounded buffering, replay that cannot double-count, and watermarks that make late data a defined case. It also means load testing at the burst rate you get after an outage, not the average rate you get on a Tuesday.
- Idempotent event identity, so replay is safe by construction
- Explicit watermarks and a defined policy for late-arriving records
- Back pressure instead of unbounded queues
- Continuous reconciliation against source counts, not month-end
- Retention tiers decided by query pattern rather than by default
When not to hire us
We do not work on network elements or anything in the signalling path. Our work sits on the data that comes out of the network, not inside it.
The engagement we decline most often is a billing migration with no parallel run. Running old and new against live traffic until they agree is the only credible way to find the discrepancies, and it has to be in the plan from the start.
Common questions
Yes, and replacing it is rarely the first recommendation. These systems encode years of commercial rules that exist nowhere else. The usual productive path is building alongside them and narrowing their responsibilities, rather than a migration whose main risk is the undocumented pricing logic.
Related work
Bring us the part that is stuck.
Send the constraint you are working around and we will come back with an approach, a rough shape of the work, and what it would take to hand it over.