Service boundaries that survive a second marketplace
Stuffing every marketplace field into one order service feels fast until the second channel arrives. Boundary decisions need a second customer in mind.
The first marketplace integration rarely looks architectural. Someone maps fields into the existing order table, ships, and celebrates. The second marketplace arrives with different cancellation rules and a different notion of “sku”, and the original shortcuts become a rewrite project.
Design as if the second channel is already funded
In Backend Service Design workshops we ask a blunt question: if another channel went live in ninety days, which tables and endpoints would you regret touching? The answers usually reveal a natural split — catalogue sync, order intake, and fulfilment signalling rarely want to share a single transactional core.
Decision records beat clever diagrams
We leave short decision records: why a boundary sits where it sits, what was rejected, and which integration use case forced the choice. Future engineers argue with the record instead of archaeology through pull requests.
Australian mid-market teams often have thin platform staffing. Boundaries that require a dedicated “platform guild” to maintain will rot. Prefer interfaces one squad can own end to end.