Platform engineering · Observability

APM Observability — Multi-tenant OTel Platform

A multi-tenant OpenTelemetry platform that connects telemetry ingestion, investigation and progressive delivery.

2025 - 2026Designer and Developer

The problem

Teams need traces, metrics and logs to lead to an operational decision—not three disconnected tools—while preserving tenant isolation and a reproducible delivery path.

Constraints

Tenant isolation must survive application-level mistakes.
The complete stack needs a no-cost local path.
Delivery evidence must be machine-verifiable, from signed images to canary analysis.

My contribution

Designed and developed the ingestion, tenancy, dashboard and delivery architecture represented in the repository.
Implemented repository-backed operational evidence including tests, architecture diagrams, canary policy and restore workflows.

Technical decisions

Isolation in the database

PostgreSQL Row-Level Security reinforces tenant boundaries below the application layer.

Trade-off: Database policy becomes part of application design and testing, but a missed query filter is no longer the only line of defense.

Provider boundaries for local-first operation

External capabilities sit behind provider interfaces with free local drivers.

Trade-off: Extra abstraction, in exchange for reproducible development without mandatory paid services.

Metrics decide canary promotion

Argo Rollouts consumes Prometheus analysis rather than relying on a manual visual check.

Trade-off: Thresholds require careful calibration; the reward is an auditable rollback path.

Verifiable outcomes

The documented canary exercise aborts automatically when the measured error rate crosses its threshold.
The repository contains dashboard, topology, test and backup/restore evidence.
The platform exposes one investigation surface for service maps, incidents, traces, issues, anomalies and DORA signals.

Product evidence

01Seeded demo data

First-party service map

Repository screenshot from the investigation dashboard using demo telemetry.

View evidence

02Repository-derived

Architecture evidence

Repository-maintained system architecture—not a portfolio reconstruction.

View evidence

03Repository-derived

Automated test report

Captured test evidence from the project documentation.

View evidence

What I learned

Observability becomes useful when it is connected to a decision and an owner.
Recovery objectives need restore exercises, not only backup configuration.

What I would change

Begin with a smaller golden path before expanding the platform surface.
Add a maintained short demo recording to every evidence-bearing release.

Next projectMental Health Viz — Reproducible Global Analytics

APM Observability — Multi-tenant OTel Platform

The problem

Constraints

My contribution

Technical decisions

Isolation in the database

Provider boundaries for local-first operation

Metrics decide canary promotion

Verifiable outcomes

Product evidence

First-party service map

Architecture evidence

Automated test report

What I learned

What I would change

Nawfal's Portfolio

Quick links

Contact info