Distributed Polyglot IDP
Internal Developer Platform in a polyglot monorepo: a service catalog that discovers services and dependencies from live gateway traffic, scores change risk, simulates failures and replays the architecture at any point in time. Go gateway, Rust graph engine, Laravel catalog, Spring Boot auth. Foundation and design are in place; the services are being built phase by phase.
Go, Rust, Laravel, Spring Boot, Next.js, PostgreSQL, Redis, Docker
The problem
Teams running many services lose track of what runs where, who owns it and what depends on what. Catalogs go stale because people update them by hand, and changes ship without anyone knowing the blast radius.
My role
Responsibilities
Sole architect and developer: the service split, the API and event contracts, a phased roadmap with exit gates, architecture decision records, and the build, starting with the gateway, auth and catalog.
Main workflows
- 1.A team registers a service with an owner, lifecycle and tier, and every change is written to an audit log
- 2.The Go gateway observes real traffic and emits events; the Rust engine turns them into observed dependency edges and flags drift against the declared catalog
- 3.Before a promotion, the engine computes the blast radius and a risk score with a factor breakdown; high scores require approval
- 4.A failure simulation shows which services degrade, and in what order, if a chosen service goes down
- 5.Event-sourced history answers what the architecture looked like at a past time and what changed between two moments
Architecture
- Current status: monorepo, Docker setup, CI, contracts, decision records and roadmap are in place; the services are scaffolds and the workflows above are the designed behaviour, built phase by phase
- Polyglot split by workload: Go gateway for edge traffic, Spring Boot for identity (JWT and JWKS), Laravel for the catalog and approvals, Rust for graph computation, Next.js for the developer portal
- Contract-first: OpenAPI for HTTP and a broker-agnostic event envelope with versioning rules
- Postgres outbox first, Kafka only when replay and multiple consumers justify it, recorded as an architecture decision
- Each service owns its data; path-filtered CI and one docker compose up for the whole stack
Security and deployment
- JWTs issued by the auth service and verified by every service through a JWKS endpoint
- Role-based access per team, service and environment is part of the design
- Secrets stay in git-ignored environment files, with pre-commit hooks running secret scanning
- An audit trail of every catalog change and approval is part of the first phase