piyushsachdeva/ai-observability-with-otel-and-honeycomb

1. This repo is a Kubernetes-based demo application for URL shortening and observability. The main application stack lives under honeycomb-demo/, with Kubernetes manifests, OpenTelemetry config, service entrypoints, and operational scripts.

2. The core runtime is split into three application services: link-service, redirect-service, and stats-service. Their main.go files under patches/services/* suggest each service is independently deployable and wired from a shared codebase or patches layer.

3. link-service is the write path. The presence of patches/internal/adapters/repository/postgres/link.go shows a repository adapter for storing link records in PostgreSQL, so this service is the main persistence boundary for created short links.

4. redirect-service is the read/serve path. It likely resolves a short code into a destination URL and handles the high-volume redirect traffic. This is the most latency-sensitive service in the system.

5. stats-service is the analytics boundary. It aggregates or exposes usage data for links/redirects, likely reading from the database and/or a cache rather than serving the redirect path directly.

6. PostgreSQL is the primary durable datastore, deployed via k8s/02-postgres.yaml. Redis is a separate infrastructure component in k8s/03-redis.yaml, which implies the app uses a fast ephemeral store for caching, counters, or request state.

7. Observability is first-class. k8s/04-otel-collector.yaml and otel/collector-config.yaml define an in-cluster OpenTelemetry Collector, and patches/otel/otel.go indicates shared instrumentation setup inside the services. Telemetry is therefore routed through the collector rather than sent directly from each service to a backend.

8. k8s/05-feature-flags.yaml adds a feature-flag subsystem inside the cluster. That makes runtime behavior configurable without redeploying the services, which is important for demos and controlled experiments.

9. The user-facing edge is split between frontend, nginx, and ingress. frontend is the UI layer, nginx likely serves or reverse-proxies it, and k8s/11-ingress.yaml exposes the stack externally. Requests then fan out from the ingress to the frontend and API services.

10. Deployment is fully Kubernetes-native and ordered by numbered manifests: namespace, secrets, backing services, observability, app services, edge, and ingress. k8s/01-secrets.yaml is the shared configuration boundary for credentials and sensitive settings.

11. The scripts/ folder defines operational workflows around the app: apply.sh deploys the stack, load-test.sh generates traffic, and inject-chaos.sh / remove-chaos.sh support resilience testing. These are not part of the product path, but they are important to the repo’s demo architecture.

12. ubuntu-nodegroup.yaml suggests the cluster runs on a cloud-managed node group, so the deployment model is “Kubernetes on provisioned Linux worker nodes” rather than a local-only demo.

13. For an architecture diagram, the key flows are: external user traffic enters through ingress/nginx to the frontend and API services; link-service writes to Postgres; redirect-service serves redirects and may consult Redis/Postgres; stats-service reads aggregated data; and all services emit telemetry to the OpenTelemetry Collector, which is the central observability hub.