$ ls /var/reports — 7 entries
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 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
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
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
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
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
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
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)