Architecture: How should API Dev Tools instrument request tracking across ...

Documentation for Sessions

🏗️ Architecture: How should API Dev Tools instrument request tracking across ...

Date: 2026-03-17
Time: 17:16:42 UTC
Session: gspace1-229.4
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should API Dev Tools instrument request tracking across all 4 backend APIs?

Task: Not specified

🎯 Decision Made

Chosen:

Shared RequestActivityModule in @libs-api/backend-core with forRoot() dynamic module pattern. Each API imports RequestActivityModule.forRoot({ apiName, bufferSize, excludePaths }) — one line per API. The module provides APP_INTERCEPTOR globally, an in-memory O(1) circular ring buffer (RequestActivityStore), a DevActivityController with @Roles guard, and a DevActivityGuard that returns 404 in production.

Options Considered:

  1. Per-API interceptor (duplicate code in each API)
  2. External telemetry service (OpenTelemetry/Prometheus — overkill for dev tool)
  3. MongoDB-backed store (persistent but adds dependency and latency)
  4. Redis pub/sub with central aggregator (complex, multi-service coordination)

💭 Reasoning

Putting instrumentation in the shared backend-core library means all 4 APIs get identical behavior with zero code duplication. The forRoot() pattern allows per-API configuration (apiName for identification, excludePaths for SSE-heavy APIs like vitto-api). APP_INTERCEPTOR is global by design in NestJS, so it captures all HTTP requests automatically. The ring buffer avoids MongoDB/Redis dependency — this is a dev tool, not a production telemetry system. O(1) circular buffer with head pointer avoids the O(n) cost of Array.shift() at scale.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation