Distributed Tracing for a Polyglot Microservice System
Instrument a system of services written in several languages so a single request can be followed end to end, then use the traces to find and fix real bottlenecks. The measured before and after is what makes this a project rather than a configuration exercise.
Intermediate
A small team, or one strong student willing to learn something new.1 semester, 2 students
5 to ship
3 optional extrasSuggested stack
What you should ship
- A reference system of at least 4 services in at least 3 languages with realistic inter-service calls
- Context propagation working across every language boundary, including asynchronous message paths
- Trace collection and storage with sampling, plus a documented analysis of sampling overhead
- Latency analysis identifying the critical path and the top contributors to tail latency
- At least 3 performance problems found through tracing, fixed, and the improvement measured
If you have time left
- Automatic service dependency map derived from collected traces
- Anomaly detection on trace latency distributions
- Correlating traces with logs and metrics through a shared identifier
The problem
When a request through eight services is slow, logs tell you each service was fine. The latency is in the gaps, in queuing, in a retry, in a call nobody knew was synchronous, and only a trace that follows the request end to end shows it.
What you build
A realistic polyglot reference system, full context propagation, trace collection, and an analysis that finds and fixes real problems.
Why multiple languages is the point
Context propagation is straightforward within one language and awkward across boundaries, especially through message queues and background jobs where the context must be serialised and restored. Making that work is the technically interesting part.
The result that makes the project
Three fixed performance problems with before and after numbers. Something like discovering a service making the same call four times per request, or a retry with no backoff amplifying a slow dependency, then fixing it and showing the p99 improve. Without this you have a configuration exercise; with it you have an engineering result.
The trade off to measure
Sampling. Tracing everything is expensive, sampling loses the rare slow requests you most want to see. Measure the overhead at different rates and discuss tail-based sampling.
Scope warning
Do not write a tracing backend. Use an established one and spend the time on instrumentation and analysis.
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. Every session is free; a few slots open each week.
Follow along
New writing, resources and project ideas land here first.