Distributed Tracing for a Polyglot Microservice System
Instrument a microservice system written in several languages with OpenTelemetry so one request can be followed end to end, then use the traces to find, fix and measure real bottlenecks. An observability final year project for backend and DevOps students, judged on measured before and after results.
Intermediate
A small team, or one strong student willing to learn something new.1 semester · 2 students
7 to ship
3 optional extrasSuggested stack
What you should ship
- A reference system of at least 4 services in at least 3 languages, with synchronous HTTP or gRPC calls and at least one asynchronous message path
- Context propagation working across every language boundary, including through the message queue and a background worker
- An OpenTelemetry Collector pipeline exporting to Jaeger or Tempo, with head sampling and tail sampling configurations
- A measured analysis of instrumentation and sampling overhead on throughput and latency at several sampling rates
- Critical-path and tail-latency analysis identifying the top contributors to p99 latency for two key user flows
- At least 3 performance problems found through traces, fixed, and the p95 and p99 improvement measured under the same k6 load
- Traces linked to logs and metrics through a shared trace ID, shown in one Grafana view
If you have time left
- Automatic service dependency map derived from collected traces
- Anomaly detection on per-endpoint latency distributions
- A short workshop or lab sheet that uses your system to teach tracing to juniors
The problem with slow requests across many services
When a checkout request passes through six services and takes three seconds, each service's logs say it was fine. The latency is in the gaps: time waiting in a queue, a retry nobody knew about, a call that looked asynchronous but blocks, or the same downstream call made four times per request. Only a trace that follows the request end to end shows it.
This hurts any team that has split a product into services, which today includes many software houses and product startups. It is worse when the services are written in different languages, because each one was instrumented (if at all) by a different person with a different library.
What already exists and the gap
- OpenTelemetry is the vendor-neutral standard for traces, metrics and logs, with SDKs for most languages and a Collector for processing and export.
- The OpenTelemetry Demo (Astronomy Shop) is a microservice shop in many languages that shows instrumentation in a near real-world setting.
- Jaeger and Grafana Tempo are open-source tracing backends; hosted services such as Honeycomb and Datadog offer the same with analysis on top.
The tools exist and the demo already works, so simply installing them is not a final year project. The gap is the engineering result: getting propagation right across awkward boundaries (queues, background jobs, languages), measuring what tracing costs, and using traces to find and fix problems with numbers to prove it. That is what teams need from a new engineer and what most write-ups skip.
What you build
- A small, realistic system, for example an order flow: a Node.js gateway, a Go order service, a Python pricing service, a worker consuming from RabbitMQ or Kafka, and a database.
- OpenTelemetry instrumentation in every service, automatic where possible and manual where it matters (business spans, queue producer and consumer).
- A Collector pipeline with batching, sampling and export to Jaeger or Tempo, plus Prometheus metrics and structured logs carrying the trace ID.
- A k6 load script that exercises the main flows repeatably.
- Deliberately realistic problems to discover: an N+1 query, a retry without backoff, a synchronous call that should be parallel.
The technically interesting part
Propagation across boundaries is straightforward inside one language and awkward across them. Through HTTP it is a header; through a message queue the context must be written into message headers by the producer and restored by the consumer, and a batch consumer has to decide whether one message's trace is a parent or a link. Show a single trace crossing all three languages and the queue without a break.
Sampling is the trade-off to measure. Tracing everything costs CPU, network and storage; head sampling at a low rate loses the rare slow requests you most want. Tail sampling in the Collector keeps errors and slow traces but needs memory to hold spans until the trace completes. Measure overhead at several rates and show which slow requests each configuration kept or lost.
How to evaluate it
- Coverage: percentage of requests in a load run whose traces are complete across all services, target 100 percent at full sampling.
- Overhead: throughput and p99 latency with tracing off, head sampling at 100, 10 and 1 percent, and tail sampling, under the same k6 load.
- Findings: three problems found through traces, each with the trace screenshot, the fix and before and after p95 and p99.
- Usability: give a classmate a planted bug and time how long they take to find it with traces versus logs only.
Suggested plan
- Weeks 1 to 3: build the reference system and load script without instrumentation; record baseline numbers.
- Weeks 4 to 6: instrumentation in every language, HTTP and queue propagation, Collector and backend.
- Weeks 7 to 8: logs and metrics correlation, sampling configurations.
- Weeks 9 to 11: overhead measurements, critical-path analysis, find and fix problems.
- Weeks 12 to 14: usability test, report and demo.
Path to a product
This is a portfolio and teaching project more than a startup. The reference system plus a lab sheet is useful to universities teaching distributed systems and to companies onboarding engineers to observability. Publish it as open source; a well-documented polyglot tracing lab with measured overhead numbers is rare and gets noticed. The skills lead directly to backend, platform and SRE roles, and to consulting for teams adopting OpenTelemetry.
Scope warning
Do not write a tracing backend or your own instrumentation library. Keep the system to four to six services. Do not add a service mesh unless you have finished everything else. Spend the time on propagation, measurement and fixes.
Learn what you need on Sefism
- System design roadmap : microservices, queues and latency concepts behind the traces.
- Backend roadmap : APIs, databases and background jobs you will instrument.
- DevOps and cloud cheat sheet : containers, Compose and monitoring basics.
- Grafana k6 Documentation : write repeatable load tests for before and after numbers.
- Discord Engineering : real write-ups of finding latency problems in large systems.
Get help with this idea
This idea is strong when the results are measured, not just configured. Tauseef can help you design the reference system, choose realistic problems to plant, and plan an evaluation that examiners will respect. If you are new here, create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.