// the take
A runnable example of a Go microservices stack — HTTP frontend fanning out to gRPC services for a fake hotel-booking app — with OpenTelemetry tracing into Jaeger. It's aimed at developers who want to see how HTTP-to-gRPC composition, health/readiness checks, and distributed tracing fit together, not at anyone looking for a service they can drop into production.
Service boundaries are realistic: frontend talks HTTP, internal services talk gRPC, and search actually fans out to geo and rate concurrently, which is the pattern people actually need to see. Tracing isn't bolted on as an afterthought — every service exports to Jaeger and the README walks through a real failure scenario (kill search, hit /readyz, get a correct 503) instead of just claiming the endpoints exist. Each service has its own _test.go, and make check-generated guards against committing stale protobuf/go-bindata output, which is the kind of generated-code hygiene most demo repos skip. Runs identically with or without Docker, so you can read the code and run it in minutes.
It's a teaching fixture, not a system: 'data' is static JSON baked in via go-bindata, so there's no real persistence story to learn from or extend. consul is listed as a topic but the README shows hardcoded ports with no actual service discovery wired into the gRPC calls — if you came here for that, it isn't demonstrated. There's no auth/authz anywhere, and no TLS or mTLS between the gRPC services, which matters a lot if someone copies this as a starting template rather than reading it as an example. Tracing is a single local Jaeger instance with no mention of sampling or retention, so it illustrates the wiring but nothing about running OTel at any real scale.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →