CreatorOps

The flow covers program, creator, coupon or link, sale, commission and payout. Business rules come before technology: a valid coupon beats a click, a confirmed attribution is never silently rewritten, a late event does not move an order back, money is never a float, and the ledger only takes new entries. A refund after a payout reduces the available balance, can leave it negative, and never silently undoes a transfer that was already confirmed.

It is a modular monolith with nine boundaries: identity, programs, partnerships, attribution, commissions, content listening, finance, agent control and reporting. The choice is deliberate, because the goal is to study transactional rules, and each boundary can become a service when volume, team size or isolation justify it.

Anything that changes a decision or money opens a transaction in the service. Locks (SELECT … FOR UPDATE), unique constraints and partial indexes protect invariants under concurrency, and the domain event goes into the outbox in the same transaction. Publishing is at-least-once, and each consumer records the inbox before accepting any effect.

The ledger works in pairs of entries per bucket: a commission starts as pending, is settled to available, reserved in the payout batch and confirmed as paid, or returns to available if the transfer fails.

The hard case is the ambiguous payout. If the provider processes the transfer and the response is lost to a timeout, the payout stays unknown and the reservation remains: no response does not prove it failed. The system never creates a second idempotency key; it asks the provider using the original one. The fix goes through an immutable finding with evidence and a hash, a proposal with no side effects, deterministic gates and finance approval with a comment. The executor repeats the gates inside the transaction, and if the version changed the proposal becomes stale.

Security: HMAC over the raw webhook body, with constant-time comparison; the staff JWT carries the active brand, but every request confirms the membership in the database; services filter by brand before loading or locking any resource; errors follow the Problem Details format, with no stack trace and no hint that another brand's data exists. Local configuration fails if the emulator addresses are missing, so it never falls back to the real cloud by accident.

A simulated payment provider fails on purpose, to prove the error path. Structured logs, Prometheus metrics and Jaeger traces.

Full stack: FastAPI, Pydantic v2, async SQLAlchemy 2, PostgreSQL 16, Alembic, Pub/Sub and Firestore on emulators. Checked with Ruff, strict mypy and tests against a real Postgres.