$ ls /var/reports — 7 entries

Incident reports.

Selected work, written the way I think about it on call: what broke or needed building, the constraint, the decision, and what I'd revisit.

Reports

INC-001 · zero-downtime-migrationRESOLVED

Moving a live datastore without losing a row

Moving a live datastore from MongoDB to PostgreSQL without losing a row — the hard part was correctness during cutover, not the schema.

PythonDjangoPostgreSQLMongoDBFeature flagsDomain-Driven Design
read the report
app
 ├─▶ mongo      (old · read)
 └─▶ postgres   (new · dual-write)
       │
  reconcile ──▶ flip read ──▶ retire mongo
  · rollback-safe at every step ·
INC-002 · go-messaging-reliabilityRESOLVED

Keeping one slow provider from stalling everyone

One slow SMS provider could stall all of them. Lane isolation over a shared priority queue; a targeted cache cut analytic-store load 85–95%.

GoKafkaClickHouseRedisEvent-driven
read the report
inbound ▶ ┌─────────────┐
          │  dispatcher │
          └──────┬──────┘
       ┌─────────┼─────────┐
       ▼         ▼         ▼
[lane A]     [lane B]   [lane C]   topic·DLQ·retry
       ▼         ▼         ▼
provider A  provider B  provider C
            (slow)
INC-003 · modular-monolithOPERATING

A monolith that doesn't rot

Scaling a team and product without scattering into premature microservices — ~80 bounded contexts in one deployable, each with an isolated queue.

PythonDjangoCeleryRabbitMQKubernetesMulti-tenant SaaS
read the report
┌──────── one deployable ─────────┐
│ [loyalty▸q] [payments▸q]        │
│ [messaging▸q] [crm▸q] … ~80     │
│ bounded contexts · isolated q   │
└─────────────────────────────────┘
INC-004 · payment-gateway-registryOPERATING

Making cross-provider payments idempotent

The interesting part of multi-provider payments isn't the integrations — it's the idempotency that makes a double-spend impossible.

PythonDjangoDomain-Driven DesignPayments
read the report
checkout / invoicing / settlement
         │
   [domain interface]
  initiate · verify · settle
         │
 ┌───────┴────────┐
 │ idempotency    │  ← double-spend guard
 │ guard          │
 └───────┬────────┘
 ┌───────┴────────┐
 [strategy A] [strategy B] …
 (provider-specific · self-registering)
INC-005 · cluster-cost-attributionRESOLVED

Making cluster spend visible enough to cut

You can't cut what you can't see: attributing cluster spend per product line made a −30% reduction obvious.

PythonKubernetesPrometheusGrafana
read the report
prometheus metrics + workload labels
         │
 [attribution tool]
 resource usage → product owner
         │
 grafana · per-team dashboards
         │
 teams own their footprint
 → optimizations follow
INC-006 · petros-vpn-relayOPERATING

Enforcing per-user limits without a control-plane API

The upstream offered no API for per-user limits, so enforcement was derived from observed traffic instead — a log-parsing limiter that shipped.

KubernetesNginxPythonTCP/IPDNS
read the report
┌────────── single K8s pod ──────────┐
│  nginx (traffic termination)       │
│      │                             │
│  xray (protocol handling)          │
│      │              ↑              │
│  access logs ──▶ py-limiter        │
│  (observed traffic → enforcement)  │
│  supervisord (process health)      │
└────────────────────────────────────┘
INC-007 · woocommerce-loyalty-pluginOPERATING

Putting loyalty inside the surface merchants already use

A loyalty platform is only as good as its reach — the integration had to land inside WooCommerce, not alongside it, and hook into the OTP auth merchants already run.

PHPWordPressWooCommerceREST
read the report
[Dobare platform API]
       ▲
       │  REST · webhook
       │
┌──────┴──────────────────┐
│  WooCommerce plugin     │
│  REST controllers       │
│  Gutenberg block        │
│  OTP auth bridge        │
└─────────────────────────┘
       │
merchant storefront
(theme + plugins I don't control)