Public case study · architecture and implementation

Systems / Operations

One operating layer for identity, devices, access and assets.

A Go control plane that coordinates lifecycle and reconciliation work across multiple systems without treating a partial view as the truth.

Full-stack path

  1. Management web UI
  2. Go HTTP layer
  3. Job and reconciliation layer
  4. Serialized write workers
  5. External systems

Context

Operational change crosses systems with different state, timing and failure modes. A successful request in one system does not prove the whole operation is complete.

Proof in the build
Lifecycle jobs re-read authoritative state before consequential writes and stop when inputs are incomplete or contradictory.

System

An authenticated management web UI and HTTP layer run in the Go service. Background workers coordinate idempotent work, serialize sensitive writes and record explicit outcomes.

Proof in the build
Roughly 20,000 lines of Go run as one binary with an HTTP API, authenticated UI and two worker pools with different concurrency guarantees.

Sanitized system view

Lifecycle state, before any write.

Representative workflow using no live identity, device or asset data.

Lifecycle / Reconcile

Employee transition review

Ready to reconcile

Compare authoritative identity, device and asset state before scheduling cross-system changes.

Authoritative state

HR event + Okta identity

Managed context

Jamf device + asset assignment

Reconciliation checks

  • Source records agree
  • Required ownership is known
  • Write order is explicit
  • Every outcome is recorded

Inside the control plane

Three technical choices define the architecture.

Runtime

One Go binary, three roles

The same executable runs the OIDC-authenticated management UI and HTTP service, a concurrent Faktory worker pool or a dedicated serialized write worker. Templates and static assets are embedded.

Jobs and state

Concurrency where safe, ordering where required

Faktory handles asynchronous work. PostgreSQL and GORM hold durable application state, while sensitive external mutations use a deliberately serialized path.

Integration design

Vendor APIs stay behind service boundaries

System-specific clients own transport and data mapping. Service packages own cross-system rules, so thin handlers and workers reuse the same orchestration logic.

Guardrails

  • Verify current state before consequential changes
  • Stop on incomplete or contradictory state
  • Make repeated work safe
  • Distinguish success, no-op and failure

Scope

  • Identity
  • Devices
  • Access
  • Assets
  • HR
  • Lifecycle
  • Reconciliation

Identity estate

SSO, SCIM and RBAC across 80+ applications.

I implemented and managed the Okta identity layer across a broad application estate, including authentication, provisioning and role-based access design.

In-house SCIM in Go

Access governance built into the control plane.

The Go platform uses Okta group membership as its source of truth, then grants, revokes and continuously reconciles downstream access through a custom-built SCIM provisioning engine.

Result

A single operating layer for cross-system work, with clearer failure behavior and stronger operational evidence.