Product request
Browser
Nginx
Next.js
Product interface
Bun owner service
The UI does not reach into Product tables. It crosses an application boundary with a validated result.
Selected projectsEngineering case study / 2026
Private codebase · Sanitized public record
Product architecture / platform engineering / resilient delivery
OpenReels
I took a working video and social platform whose services were separated mostly on paper—and made its boundaries testable, its failures visible, and its releases safer to operate alone.
16
independent component images
plus three Worker bundles and a recovery artifact
1,019
listed passing tests
across contracts, services, infrastructure, routes and policy
82
governed database relations
63 owner tables and 19 consumer Read Models
20
release-manifest subjects
all bound to one exact source revision
01Context
The difficult part was not adding more services.
OpenReels already had Next.js, Bun processes, PostgreSQL, Redis, RabbitMQ, private object storage and an authenticated CDN path. It looked service-oriented. In practice, pages still knew transport details, processes shared schema knowledge, local development needed too much infrastructure, and a failed dependency could quietly masquerade as an empty screen.
At the same time, production behaviour already mattered. I could not “clean up” the architecture by casually replacing protected media, rewriting the database, or weakening the exact-SHA release path. The migration had to improve changeability while keeping every existing safety boundary explainable and recoverable.
A process boundary is not a product boundary if callers still share its assumptions, tables and failure shortcuts.
Before
After
Service boundaries were visible in the process diagram.
Product boundaries became executable through shared runtime contracts and owner interfaces.
A dependency outage could look like an empty product state.
Empty and Unavailable became different results, with different UI and recovery behaviour.
Frontend work could require the database, queue, mail, storage and cloud configuration.
Real routes run against deterministic, authenticated scenarios without Docker or cloud credentials.
Processes shared schema knowledge and convenient cross-domain access.
Owners write their own state; other modules use contracts, Read Models, events or commands.
02Architecture
Three paths, each with a different trust boundary.
This public map deliberately excludes credentials, internal addresses and operating procedures. It shows responsibility—not exploitable topology.
State and effects
Owner transaction
PostgreSQL
Owner outbox
RabbitMQ
Consumer receipt
A state change and its message are committed together; consumers remain safe under at-least-once delivery.
Protected bytes
Upload session
Private ingest
Owner verification
Exact media grant
Cloudflare Worker
Authentication and authorization happen before cache or object access, including HEAD and byte-range requests.
Product
Next.js 16 · React 19 · Bun
State
PostgreSQL 15 · Redis 7
Messaging
RabbitMQ 4 · owner relays
Delivery
Cloudflare Workers · private R2
03Decisions
The choices that changed how the system behaves.
These were not technology swaps. Each decision changed who owns a fact, how failure is represented, or what evidence is required before a change becomes real.
01
Make product meaning executable
TypeScript types alone cannot protect a process boundary. I introduced Zod contracts for requests, results, failures, events and adapter parity.
Live HTTP and Socket adapters satisfy the same interfaces as deterministic scenario adapters. This catches drift at the seam and lets the frontend represent dependency failure honestly instead of silently turning it into “no data”.
223 contract and adapter-parity tests
02
Enforce ownership before splitting databases
A database-per-service rewrite would have increased operational risk without solving the immediate design problem.
I kept one PostgreSQL cluster, then made ownership real through eleven checksummed owner migration streams, distinct runtime roles, owner commands, consumer Read Models and a blocking source scan. The app has connectivity for health checks but no Product-table privilege.
63 owner tables · 19 Read Models · 11 owner ledgers
03
Design asynchronous work for duplicates and failure
Publishing after a database commit leaves a crash window. Publishing before it risks announcing state that never existed.
Transactional owner outboxes, independently credentialed relays, RabbitMQ confirms and consumer-owned receipts make at-least-once delivery explicit. Invalid messages are quarantined, transient work retries within bounds, and redrive is preview-first and allowlisted.
4 owner relays · 9 broker identities · bounded DLQ redrive
04
Treat protected media as an authorization system
A private bucket is not enough once media is cached, streamed, renewed and removed across product surfaces.
OpenReels separates ingest, product, chat and moderation storage. Product records keep opaque asset identities, while short-lived viewer-and-asset-bound grants protect delivery. Long-lived pages renew exact visible assets without reloading the feed or weakening grant lifetime.
3 Worker programs · auth before cache · range-safe playback
05
Keep AI useful—and absent when it is unsafe
The Knowledge Assistant is a Product Module, not a chat box pasted onto the interface.
Availability requires the deployment switch, provider readiness, published knowledge and administrator enablement. If any gate fails, the user boundary returns a generic 404 and Social removes the Assistant from conversation, search and unread surfaces. The current capability is retrieval-only; no agentic tool can execute.
immutable knowledge revisions · cited answers · no executable tools
04Delivery
Production safety became a compatibility problem.
“The previous version was healthy” is not enough if contracts, database shape or trust policy have changed. Releases now carry the evidence needed to decide whether one component can move alone, whether a coordinated rollout is required, and whether application rollback remains legal.
Non-negotiable
Database evolution is forward-only. Production is a separate manual action selecting a complete, validated beta SHA.
- 01Qualify the change
A ready pull request produces a deterministic validation plan and evidence bound to the exact tested Git tree.
- 02Build exact artifacts
Sixteen minimal non-root component images and three Worker bundles are built from one full source SHA.
- 03Assemble the manifest
Digests, compatibility fingerprints, provenance subjects and the bounded recovery image become one attested release identity.
- 04Select production manually
Production accepts only a complete beta SHA. Database changes move forward; application rollback is allowed only when compatibility is proven.
- 05Prove the serving system
Health, workload trust, Workers, storage, TLS and external smoke checks must pass before finalization.
Tree-qualified CI
Validation evidence is bound to the tested tree, policy digest and selected suites—not just a green check with an ambiguous source.
Minimal artifacts
Each runtime carries its declared entry point and dependency closure, runs non-root and is selected by digest.
Pre-traffic trust proof
Candidate services and Workers prove caller identity, audience, route binding and replay rejection before ordinary traffic moves.
05Evidence
Proof, not adjectives.
The August 2026 test inventory lists 1,019 passing tests. Typechecks, schema checks, migration replays, Compose rendering, shell analysis, Worker dry runs, image inspection, vulnerability scans and external production smoke checks are additional gates—not padded into that number.
Integration suites use disposable PostgreSQL, RabbitMQ, Mailpit and MinIO. They are explicitly forbidden from targeting shared or production systems.
Executable test inventory
1,019
Architecture & ownership256
Backend behaviour290
Contracts & adapters223
Infrastructure integration73
Development runtime70
Frontend routes62
Workers & media38
Messaging integration7
Failure
dependency loss, recovery, drain and bounded retry
Security
auth, ownership, replay, cache and grant denial
Compatibility
twice-applied migrations and old/new contract overlap
Operations
health, evidence, rollback and exact artifact identity
06Outcome
The system became easier to change without becoming dishonest about its complexity.
What improved
- Frontend work can use the real Next.js routes, layouts, authentication semantics and deterministic failure states without Product infrastructure.
- A backend change can start one watched process with only the dependencies it actually needs.
- Architecture violations, contract drift and unsafe release assumptions fail before publication instead of becoming production surprises.
- Protected media, messaging and AI capability changes now include recovery behaviour as part of the feature—not as a later operations task.
Honest constraints
- OpenReels is still one private monorepo operated by one developer.
- Compact production retains one PostgreSQL failure domain and 21 documented cross-owner foreign keys.
- Some legacy Server Actions still map transport details outside deeper Product interfaces.
- The provider-neutral Scale package is executable design evidence, not proof that multi-region production is active.
- Repository-wide lint still has a visible historical backlog; touched code must not make it worse.
What I took from the work
Reliability starts with language.
Once Empty, Unavailable, Event, Command and owner boundaries had precise meanings, the code and tests became much easier to reason about.
Security is a complete path.
A media rule is incomplete unless issuance, renewal, cache lookup, range delivery, invalidation and rollback all agree on it.
Architecture must fit its operator.
The goal was not to imitate a large company. It was to gain independent change boundaries while keeping recovery understandable for one person.