RTN Consulting

Case study · live production system

A live production platform, engineered end to end

A system RTN designed, deployed, and operates. Domain specifics are generalized; the engineering is described exactly as built. Figures as of 2026-09-12.

The user base grew more than fourfold in two months. After re-architecting from a single in-house host to a three-node containerized Docker fleet over 2026-07-12 to 2026-07-13, the base grew from 377 at cutover to 1,613, doubling in the first 13 days, with every single record preserved and zero data loss.

What it is. RTN runs a live, always-on production platform that serves end users continuously from a self-managed cloud host, in continuous operation since 2026-05-20. It was migrated from a single in-house host to a three-node containerized Docker fleet (v1.x to the current v2.1.0): the migration began 2026-07-12, all three nodes were back in production by 2026-07-13, and every single record was preserved through the move with zero data loss. The next release, v2.2.0, is planned for deployment at the end of September 2026.

The architecture. One cloud VPS (8 vCPU / 8 GB RAM) runs a Docker container fleet: three real-time application nodes, one shared database, and one update-only job. Each node is core-pinned and memory-capped, so a spike on one cannot starve the others. A single read-only application install is shared across all nodes, with a per-node writable overlay on top, and one update-only service is the sole writer to the shared install. Nodes boot in a serialized, health-gated order, so nothing starts until its dependency is genuinely up.

The custom service. Each node runs thirteen service modules, four of them built in-house in C# and running on the .NET 10 runtime. Those four started as a single module and were split by responsibility as the platform matured: scheduling and gating, unified stats, supporting features, and the client-side interface. The remaining nine are third-party, on the principle that custom code is written only where the value justifies maintaining it. A single source-of-truth VERSION file tracks the platform release in lockstep with the scheduling module.

One identity across the fleet. A single shared MariaDB database, the primary data store, gives every user one identity across all three nodes. Usage stats, usage hours, and access-control history follow the user everywhere, written through an asynchronous write-behind flusher rather than blocking the live path. One node's specialized workload keeps its per-user performance records in a secondary embedded SQLite database owned by a third-party module; consolidating both into a single database instance is planned. Application nodes never write back to the configuration source of truth.

Shipped since the migration. A custom client-side interface: 30 elements each user can toggle, saved per user in the shared database, shipped in two halves on separate release cadences. A milestone engine: 180 definitions generated from a 218-row CSV source of truth, 7,525 milestones earned by 1,430 users. Earned milestones are append-only and season-scoped; a threshold can be lowered but never raised, because raising one would revoke what users already earned. Three machine-checked contracts gate every build, each guarding a failure that is silent at runtime.

How changes ship. A separate build and staging host is the single source of truth; changes flow one way to production and never the reverse. Deployments go per-service, one node at a time: pre-flight safety backup, transfer over SSH and rsync, restart, then verification by healthcheck and liveness probe before a guarded commit that refuses the main branch, never pushes, and adds no automated attribution. A secret-scrubbing publish gate strips real addresses, tokens, and identifiers before any artifact is ever made public.

Resilience and self-recovery. The platform recovers unattended. An ordered boot unit brings the full stack up in dependency order after any reboot, each service gated on the previous being genuinely up. A self-healing check repairs a broken install every fifteen minutes and refuses an unsafe action when disk is tight, raising an alert instead. If a runtime component fails to load, the affected node drops to a degraded fallback and stays reachable rather than going dark. System package holds keep an unattended host upgrade from pulling the container runtime out from under the running fleet. Each of these was proven on live reboots on 2026-07-17.

Operations and durability. A chat-ops surface driven by operational webhooks provides a self-updating live status card refreshed every minute, action and audit logs, and a consolidated update fan-out. Every night at 00:00 UTC the shared database and nine embedded data stores are archived, each embedded store integrity-checked, then copied offsite to OneDrive and confirmed there. Every archive since 2026-07-13 is kept: more than 60 consecutive nights without a miss, growing from 81 KB to over 500 KB. A failed run raises an alert instead of passing silently, and schema changes take a named snapshot first.

The operating principle. Solve the problem at the lowest stable layer, automate the surface above it, document the runbook below. The incident below is that principle in practice, reproduced rather than summarized.

Case study · internal methodology

Document control, deployed under document control

RTNc-PROC-0005, reproduced in full below. Client- and environment-specific values are never published; the procedure is shown exactly as practiced.

RTNc-PROC-0005 governs Stage 1 verification: the automated check confirming a client's new SharePoint deployment is structurally sound before Power Automate import begins. It is one procedure from RTN's own numbered, revision-controlled work-instruction library, the same document control the Document Control System sells, applied internally to how RTN deploys it.

Case study · closed audit finding

The V-22 Osprey, an 8-year gap closed end to end

A multi-system root-cause investigation at Boeing, discovered during a supplier audit and closed audit-grade from notice to exposure assessment. The sharpest figures are rounded to protect specifics; the investigation is described exactly as run.

A U.S. Navy MV-22 Osprey. Representative aircraft, not the specific unit involved.

Case study · productized offer

Document control in weeks, on the Microsoft 365 a business already owns

The product behind Offer Ladder rung two: a document-control system built to ISO 9001 Section 7.5 with an AS9100D overlay, mapped clause by clause and deployed through a repeatable, automated pipeline. Figures describe out-of-box scope; per-engagement scope is configured to fit. RTN provides the system and starter procedures; certification and ongoing compliance remain the customer's responsibility.

Built to be audit-honest before the contract is signed: every clause covered maps to a specific product feature, and roadmap items are disclosed rather than glossed over. ISO 9001 document-control ready. The AS9100D overlay is included but not yet validated, with §8.3 Design and Development in development. ISO 13485 (medical device) is under evaluation. The go-live target follows an initial discovery and requirements-gathering phase with the client.