Work / NexusTrace

Case study 06

NexusTrace

Tracing and service health for architectures where failure has nowhere obvious to point.

The problem

When a request crosses six services, an error rate tells you that something broke. It never tells you where, and the logs of each service on their own never add up to the story.

Type
Distributed observability platform
Year
2026
Primary language
Go
Domain
Systems
54,004bytes of Go
31,527bytes of TypeScript
P99latency, live

The system

A Go backend carrying OpenTelemetry-compatible span models, with a Next.js and TypeScript dashboard over WebSockets. Traces render as a waterfall timeline, dependencies as an interactive service graph, and logs correlate to traces by ID so a failing request can be followed end to end. Alert rules fire on error rate, latency and health.

Backend
Go 1.22, OpenTelemetry-compatible spans
Frontend
Next.js 14, TypeScript, WebSocket live updates
Storage
PostgreSQL 16, optional
Views
Dashboard, traces, metrics, logs, dependencies, alerts
Demo
Built-in simulator generates realistic microservice traffic

The result

Requests per second, error rate and P95 and P99 latency stream live. A CLI covers every operation the API exposes, so the platform is usable without opening the dashboard at all.

Go 1.22TypeScriptNext.js 14PostgreSQLWebSocketOpenTelemetry

Read the code

Let's build something useful.

Send the problem, not a spec. I reply with an approach and a scope I can hold to.

Start a project