OpenTelemetry Light Branch

[kerneljack]

Hello, I created this to enable us to have a more in-depth discussion of how we could go about creating a light branch of the repo.

Since there's a lot of apps and I don't have deep knowledge of how they all work, I asked Claude Code to analyse them for me and suggest ways a light branch could be created based on this initial Github issue: #2195

Implementation Approaches

1. Docker Compose Profiles (Community-preferred)

Add profiles to services in the main docker-compose.yml:

services:
  frontend:
    profiles: ["full", "light"]
  cart:
    profiles: ["full", "light"]
  kafka:
    profiles: ["full"]  # Heavy services excluded from light

Usage:

docker compose --profile light up

Pros	Cons
Single source of truth (no file drift)	Complex dependency chains need careful handling
Native Docker feature	PR #2396 attempted this but stalled
Easy to add more profiles later (e.g., "observability-only")	Requires updating existing compose file structure

---

2. Separate Compose Override File (Simplest)

Create docker-compose.light.yml that only includes the 5 core services + minimal dependencies:

docker compose -f docker-compose.light.yml up

Proposed light services:

• Frontend, Frontend-proxy, Product-catalog, Cart, Checkout, Payment
• Valkey (cart storage), OTel Collector, Jaeger (minimal observability)

Pros	Cons
Already a pattern in the repo (docker-compose.minimal.yml exists)	File drift over time
No changes to main file	The existing "minimal" file still has ~27 services
Simple to understand	Duplication of service definitions

---

3. Make Services Standalone-capable (Most Robust)

Modify services to gracefully handle missing dependencies:

// Example: checkout service
if emailClient == nil {
    log.Info("Email service unavailable, skipping notifications")
}

Changes needed:

• Add fallback/mock responses when services are unavailable
• Make depends_on optional via environment variables
• Frontend handles missing recommendation/ad services gracefully

Pros	Cons
Services become more resilient	Requires code changes in multiple services/languages
Enables any combination of services	More complex to implement
Better for development/testing	Needs coordination across language maintainers

---

4. Makefile Targets with Service Composition

Add new targets that compose the right services:

LIGHT_SERVICES = frontend frontend-proxy product-catalog cart checkout payment valkey-cart otel-collector jaeger

start-light:
    docker compose up $(LIGHT_SERVICES)

Pros	Cons
No compose file changes	Dependency ordering must be handled manually
Easy to document different combinations	Less discoverable than profiles
Works today with existing setup	Users need to know about Makefile targets

---

5. Environment Variable Configuration

Use .env.light to disable services:

ENABLE_KAFKA=false
ENABLE_FRAUD_DETECTION=false
ENABLE_ACCOUNTING=false

Combined with conditional service definitions in compose.

Pros	Cons
Flexible configuration	Requires compose file restructuring
Easy to toggle individual services	Can get complex with many toggles
User-friendly approach	Docker Compose conditional logic is limited

---

Suggested Approach

The suggestion is to implement a combination of 1 & 3 but of course we can discuss this further.

After i got additional feedback from @julianocosta89 I asked Claude not to create more docker-compose files, but rather to modify the existing minimal file instead. This is the output after that:

Constraints from Community Feedback

Based on maintainer feedback, the implementation must:

1. Use the existing docker-compose.minimal.yml - no new compose files
2. Keep OpenSearch enabled - required for logs (see analysis below)

---

Current Service Analysis

Services in docker-compose.minimal.yml (27 total)

Core Business Services

Service	Language	Memory	Required for Core Flow?
frontend	Node.js	250M	Yes
frontend-proxy	Envoy	65M	Yes
cart	.NET	160M	Yes
checkout	Go	20M	Yes
payment	Node.js	140M	Yes
product-catalog	Go	20M	Yes
shipping	Rust	20M	Yes (checkout dependency)
currency	C++	20M	Yes (checkout dependency)
email	Ruby	100M	Yes (checkout dependency)

Non-Essential Business Services

Service	Language	Memory	Can Remove?
ad	Java	300M	Yes
recommendation	Python	50M	Yes
product-reviews	Python	500M	Yes
quote	PHP	40M	Maybe (shipping uses it)

Infrastructure Services

Service	Memory	Can Remove?
llm	50M	Yes (only for product-reviews)
postgresql	~200M	Yes (only for product-reviews)
load-generator	120M	Yes (optional traffic)
valkey-cart	20M	No (cart storage)
flagd	75M	Maybe (feature flags)

Observability Stack

Service	Memory	Can Remove?
otel-collector	200M	No (telemetry ingestion)
jaeger	400M	No (traces)
prometheus	200M	No (metrics)
grafana	175M	No (visualization)
opensearch	1G	No (logs - see above)

---

Recommended "Light" Configuration

Services to Keep (~8-12 services, ~1.5-2GB RAM)

Core Shopping Flow:

• frontend
• frontend-proxy
• product-catalog
• cart
• checkout
• payment
• shipping
• currency

Essential Infrastructure:

• valkey-cart (cart storage)
• flagd (feature flags - optional but recommended)

Observability Stack:

• otel-collector
• jaeger
• prometheus
• grafana
• opensearch

Services to Remove (~1.5GB+ savings)

Service	Memory Saved	Notes
ad	300M	Non-essential
recommendation	50M	Non-essential
product-reviews	500M	Non-essential, heavy
llm	50M	Only needed by product-reviews
postgresql	~200M	Only needed by product-reviews
load-generator	120M	Optional traffic simulation
quote	40M	Can be removed if shipping mocks it
email	100M	Requires checkout code change

Total potential savings: ~1.3-1.5GB RAM

---

Implementation Challenges

Hard Dependencies in Checkout Service

The checkout service (src/checkout/main.go) has hard dependencies:

depends_on:
  cart:
    condition: service_started
  currency:
    condition: service_started
  email:
    condition: service_started
  payment:
    condition: service_started
  product-catalog:
    condition: service_started
  shipping:
    condition: service_started

To remove email, the checkout service would need code changes to make email optional.

Frontend Dependencies

The frontend has dependencies on:

• ad (for advertisements)
• recommendation (for product suggestions)

These can likely be removed more easily if the frontend gracefully handles missing services.

---

Next Steps

1. Decide on approach: Docker profiles vs. modifying minimal compose file
2. Identify services for removal: Based on analysis above
3. Test dependency removal: Verify which services can be removed without code changes
4. Update documentation: Document the light configuration usage
5. Consider code changes: For making services handle missing dependencies gracefully