How do I position feature flags when moving from Gitflow to Trunk-Based?
Drop the long-lived branches, merge small changes to main continuously, keep unfinished work behind a flag that's off in prod, and delete flags once done.
Tag
Design choices that set system boundaries, dependencies and the decisions you cannot undo.
13 answered questions carry this tag.
Drop the long-lived branches, merge small changes to main continuously, keep unfinished work behind a flag that's off in prod, and delete flags once done.
Move reporting to a read replica and adopt CQRS only when query shapes outgrow one schema, feeding the read model from outbox events, not dual-writes.
Keep products, prices and orders in PostgreSQL and put the variable attributes in one GIN-indexed `JSONB` column; reporting alone rules out splitting.
Split the critical path (browse, cart, checkout) from the nice-to-haves, put those behind feature flags with short timeouts, and rehearse the kill-switch.
A breaker alone won't hold: pull `connect_timeout` and `timeout` down to 800ms-2s, isolate the dependency behind a bulkhead, and define a cached fallback.
For most greenfield products, start with a modular monolith and enforce boundaries in code, promoting a module to a service only when it must scale alone.
Database-per-tenant does not scale operationally at 10k; keep tenant_id on every table and bury isolation in Postgres Row-Level Security instead.
Verify the HMAC constant-time over the raw body, return 200 fast and enqueue the work, and let a UNIQUE constraint on event_id enforce once-only.
Shift payments at the gateway by 5/20/100 and validate in shadow first; the real work is splitting the tables, behind an anti-corruption layer and outbox.
Standardize on W3C Trace Context, leave propagation to the OTel SDK, and put traceparent in the queue message header, since that is where the chain snaps.