Systems / Operations
A Go control plane that coordinates lifecycle and reconciliation work across multiple systems without treating a partial view as the truth.
Choose a stage to inspect its responsibility and boundary.
Stage 01
An authenticated interface makes lifecycle state, proposed work and explicit outcomes reviewable before and after execution.
Implementation
Server-rendered Go templates with OIDC-authenticated routes.
Boundary
The interface requests work; it does not bypass service-level validation.
Stage 02
Thin handlers normalize input, enforce authentication and pass validated requests into the same services used by background workers.
Implementation
Go HTTP API, hardened sessions and CSRF protection.
Boundary
Transport concerns stay separate from cross-system policy.
Stage 03
Durable jobs re-read authoritative state, calculate the intended result and make retries converge without repeating side effects.
Implementation
Faktory workers, service packages, PostgreSQL and GORM.
Boundary
Incomplete or contradictory source state stops consequential work.
Stage 04
Order-sensitive external mutations use a dedicated queue so competing jobs cannot race each other into an invalid result.
Implementation
A single-concurrency worker pool for sensitive write paths.
Boundary
Only work that requires ordering pays the serialization cost.
Stage 05
System-specific clients translate between vendor APIs and stable internal service contracts while preserving explicit success, no-op and failure outcomes.
Implementation
Typed API clients for identity, HR, device, access and asset systems.
Boundary
No single vendor response is treated as proof of complete cross-system state.
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.
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
Representative workflow using no live identity, device or asset data.
Lifecycle / 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
Identity / Provision
Reconcile requested entitlements with current identity state before granting, changing or revoking access.
Requested state
Okta groups + application role mapping
Decision context
Active identity + approved access scope
Provisioning checks
Fleet / Coordinate
Bring lifecycle intent and current fleet evidence together before scheduling device-side work.
Fleet state
Jamf inventory + device ownership
Lifecycle context
Employee state + action eligibility
Device checks
Assets / Reconcile
Resolve the relationship between a person, a managed device and its asset record before changing assignment state.
Recorded assignment
Asset register + managed device reference
Corroborating state
Lifecycle event + fleet ownership
Assignment checks
Three technical choices define the architecture.
Runtime
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
Faktory handles asynchronous work. PostgreSQL and GORM hold durable application state, while sensitive external mutations use a deliberately serialized path.
Integration design
System-specific clients own transport and data mapping. Service packages own cross-system rules, so thin handlers and workers reuse the same orchestration logic.
Identity estate
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
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.
A single operating layer for cross-system work, with clearer failure behavior and stronger operational evidence.