Skip to content
SYS–06Case studyAcademicDelivered term project · ÉTS

CanTelcoX

A telecom BSS moved from synchronous microservices to event-driven architecture — and five optimization stages measured one by one, including the one that produced nothing.

Type
Term project · team (ÉTS LOG430)
Domain
Telecom · BSS (portability, activation, billing, fraud screening)
Status
Delivered term project · ÉTS
Period
2026
Role
Architecture & development · messaging chassis and svc-subscription
Team
Team of 5 · 60 of the 97 commits on the branch are mine
Python 3.12 · FastAPIRabbitMQMySQL · FlywayRedisKrakenD · NGINXPrometheus / GrafanaJaegerk6Docker Composefree5GC
GitHub repository Updated : 2026-09-09

01 Summary

CanTelcoX is a mobile carrier's business system: number portability, line activation, billing, MFA, fraud screening. It moves from synchronous microservices to an event-driven architecture — 6 hexagonal services, a choreographed saga over RabbitMQ, a transactional Outbox, a dead-letter queue, distributed tracing. The deliverable I'm proudest of isn't the pattern checklist: it's the load campaign, run in five stages each with a cause identified by measurement — acknowledgement P95 divided by 2.4, saga convergence up from 47% to 100%, zero errors across 22,031 requests.

02 Context

ÉTS's software-architecture course (LOG430). The labs each isolate one pattern on the same toy application; the term project is the only place where those patterns have to hold together, on a real business domain, with external integrations you don't control and measurements you have to design yourself.

03 My role & the team

A team project: 5 contributors, 97 commits on the published branch. I signed 60 of them, mostly on the event-driven foundation and on the most complex service in the system. Every claim is verifiable in the public repository's Git history.

  • The shared messaging chassis — event envelope, outbox relay, consumer, DLQ, backoff retry, traceId propagation
  • svc-subscription end to end — domain, line lifecycle, ports, ACL, free5GC adapters, port-in and port-out
  • The choreographed saga — producers, consumers, compensation, audit trail
  • The five performance stages — k6 scenario, campaigns, NGINX load balancer, replication, HLR adapter optimization

04 Five stages, each measured

A k6 campaign ramping 10 → 50 → 100 VUs over 3 minutes, traffic entering through the load balancer. Two distinct metrics, and the distinction is the whole point: the acknowledgement of POST /v1/orders, and the saga's convergence to COMPLETED. A fast acknowledgement proves nothing if the chain behind it never completes.

952.78 → 395.97 msMeasured
acknowledgement P95 (baseline → final)
÷ 2.4 — k6 campaign of 2026-08-06
47.05% → 100%Measured
saga convergence
607/607
0% (0 / 22,031 req.)Measured
error rate
79.99 → 114.52 req/sMeasured
HTTP throughput
+43%
1.5 → 3.16Measured
complete sagas per second
× 2.1
1,467 → 0Measured
duplicated events (before → after fix)
173Tested
domain + application unit tests
60 / 97Implemented
my commits on the published branch

05 Limits

  • Academic project: lab scale, no real production load and no real users.
  • Convergence rate reaches 100%, but convergence latency P95 stays at 26.34s, above the scenario's 10s threshold.
  • Measured throughput (114.52 req/s) remains far from the brief's 1,000 ops/s target. The gap is measured and localized, not explained away afterwards: the demo topology — a single broker, three nodes on one machine — is the structural limit.
  • Team project of 5: 60 of the 97 commits on the published branch are mine.
  • The repository ships under a restrictive academic licence — readable and runnable for evaluation, with no rights granted over the other contributors' code.