Application platform
A Node.js and TypeScript modular monolith uses an embedded GraphQL gateway and enforced module boundaries without introducing distributed operations before they are justified.
Founder-owned production work
A living reference implementation.
Emberside is a founder-owned consumer software platform, not an external consulting client. It provides a current, inspectable example of how architecture, delivery, privacy, observability, and recovery decisions are made under real operating constraints.
Selected evidence, sanitized for publication.Last reviewed September 2026.
Operating context
One product. Several different failure boundaries.
Long-lived mobile clients and an evolving API must remain compatible while identity, relationships, messaging, and media carry different authorization and privacy concerns.
Background delivery and real-time messaging introduce partial failure and reconciliation. Android, backend, messaging, identity, infrastructure, and static-web surfaces move at different cadences rather than pretending to be one release.
The platform is founder-operated. That makes supportability a design constraint: changes need useful failure evidence, bounded operational work, and a recovery path that does not assume a large operations team is waiting nearby.
Platform characteristics
Capabilities described by their boundaries.
Structured data
PostgreSQL is authoritative. Durable jobs and a transactional outbox carry asynchronous work where delivery affects correctness.
Identity
Native OIDC and PKCE sessions sit behind a provider-neutral authorization boundary, with customer and operator trust treated as separate concerns.
Private messaging
A separate XMPP data plane owns protocol state and routes OMEMO-encrypted private content while the application remains the authorization control plane.
Media
Object access is designed around application-owned authorization and short-lived signed operations rather than public administrative access.
Independent delivery
Backend, messaging, Android, identity and infrastructure, and static web each have release gates suited to their distinct risks.
Infrastructure ownership
Provisioning, guest configuration, process orchestration, and application promotion have explicit ownership boundaries so one tool does not silently control every layer.
Operational evidence
OpenTelemetry, Alloy, Loki, Tempo, Prometheus, and Grafana provide correlated, content-minimized signals across requests and background work.
Selected architecture
Logical boundaries, without the attack map.
This selected logical view shows responsibility and information flow. Physical topology, addressing, administrative paths, and security-sensitive configuration are deliberately omitted.
Client boundaryMobile clients
HTTPS → TLS edge →GraphQL application API
Domain authorization and client projections
Encrypted messaging →XMPP data plane
Protocol state, ciphertext routing, and archive mechanics
Authoritative state →PostgreSQL
Separate trust boundary →Identity
Authorized signed operations →Object storage
Transactional work and outbox →Background delivery and reconciliation
API · worker · edge → telemetry collector →Logs · traces · metrics → private operator dashboards
Begin with a modular monolith
Domain boundaries are enforced in code without paying the operational cost of a distributed system before scale, isolation, or ownership provides a reason to extract them.
Separate messaging deliberately
The application decides who may connect and communicate; the XMPP service owns connection, protocol, routing, and encrypted archive mechanics. Idempotent commands, durable outbox delivery, and reconciliation repair drift between systems that do not share a transaction.
Release & delivery
A healthy process is not proof that the user path works.
Release authority is cumulative: reviewed source becomes an identified artifact, then a controlled activation, then functional evidence. Successful deployment is technical evidence—not automatic approval for public rollout.
- 01
Reviewed source
A release begins with a clean reviewed commit, locked dependencies, generated-contract checks, and repository quality gates.
- 02
Identified artifact
Backend images move by immutable digest. Mobile candidates carry signer, version, source, and hash evidence without placing secrets in the release record.
- 03
Controlled activation
The release contract requires data compatibility, recovery evidence, environment configuration, migrations, health, and a stability interval to be checked before acceptance.
- 04
Functional acceptance
Acceptance exercises authentication, authorized API behaviour, background delivery, messaging, and affected client journeys to verify more than process health.
Rollback boundary
Runtime rollback selects a previous compatible artifact. Database migrations are forward-only, so schema changes preserve a compatibility window and use roll-forward recovery where reversal would be unsafe. Android correction normally requires a new, higher-version build rather than a remote downgrade.
Privacy-aware observability
Follow causality without collecting the product.
Investigation begins with an opaque correlation identifier and follows work across the edge, API, database or outbound dependency, outbox publication, and background delivery.
Logs record allowlisted outcomes. Traces explain timing and causality. Metrics describe bounded system health. A transport-level success can still contain a GraphQL operational error, so both layers are measured.
Request bodies, GraphQL variables, credentials, message text, profile data, and other personal content are excluded from logs and span attributes. Business identifiers do not become metric labels. No-work jobs and successful health probes use traces and metrics without producing repetitive outcome logs.
Asynchronous work preserves correlation across producer and consumer spans. Collection and retention are bounded, dashboards remain on a private operator surface, and the application continues operating if telemetry is impaired, with bounded local logging as the first fallback.
Operational lessons
Failure teaches at the boundaries.
These lessons are generalized from operated infrastructure. Identifying topology, incident dates, durations, and internal access details have been removed.
Verify behaviour, not the control-plane label.
A service can report that it is running while no longer listening where a dependent system needs it. Readiness must validate the path that is actually used.
Build policy from observed traffic.
Proxy and firewall rules should use captured, verified source behaviour. Network names and assumed gateway paths are not evidence, especially when forwarded identity affects authorization or audit records.
Storage paths are availability design.
A hard network mount combined with asymmetric routing can strand writes and prevent a clean shutdown. Route symmetry, timeout behaviour, and recovery need to be tested as one system.
Recovery is a set, not a file.
For encrypted virtual infrastructure, one copied security device is not an independent recovery plan. Firmware state, machine configuration, encrypted data, headers, and offline recovery material must be captured and exercised together.
Selected architectural decisions
Choices remain conditional.
Each decision records the constraint, the chosen boundary, its cost, and the evidence that would justify revisiting it.
Modular monolith before microservices
- Constraint
- Sensitive rules need clear ownership without unnecessary distributed failure modes.
- Choice
- One Node.js/TypeScript deployable with enforced domain boundaries and extraction-ready contracts.
- Trade-off
- Modules still share a process and release cadence.
- Review trigger
- Measured scale, isolation, or team ownership justifies a network boundary.
Separate messaging control and data planes
- Constraint
- Mobile encrypted messaging needs long-lived protocol state while application authorization stays authoritative.
- Choice
- Synchronize desired state to a separate XMPP service through idempotent commands, a durable outbox, and reconciliation.
- Trade-off
- Eventual consistency and explicit repair machinery are accepted.
- Review trigger
- Convergence measurements or a security incident show the boundary is inadequate.
Promote immutable artifacts, not labels
- Constraint
- A successful build does not prove deployed bytes are the reviewed bytes.
- Choice
- Connect source revision, digests, signatures, provenance, activation, and acceptance evidence.
- Trade-off
- More release bookkeeping and surface-specific gates.
- Review trigger
- A new deployable surface, changed runner trust, or a major incident exposes a missing gate.
Treat deployment and rollout as different approvals
- Constraint
- Automation cannot prove product readiness, recovery ownership, device behaviour, or distribution policy.
- Choice
- Source, artifact, deployment, functional acceptance, and product rollout remain cumulative gates.
- Trade-off
- A green pipeline can legitimately stop short of launch.
- Review trigger
- Gates become routinely bypassed or too unreliable to provide useful evidence.
A current practice
Operate the boundaries you recommend.
Operating a platform with unclear release, recovery, or observability boundaries?
Request an infrastructure review