Communicationeasy0-2 years
A checkout method inside one `@Transactional` call reserves stock, sends a confirmation email, awards loyalty points and tracks analytics — four calls to four services. Which of these should stay synchronous, and what's the test for deciding?
Only stock reservation should stay synchronous: the order doesn't genuinely exist until stock is reserved and the row is committed, so that call has to succeed for the order to succeed. The email, the loyalty points and the analytics event are consequences of the order existing, not conditions for it — they can happen a second later and must not decide whether checkout fails. The test is: if this call failed right now, should the caller fail? Yes for stock; no for the other three, which means they should be events the order service publishes after committing, not calls it makes before committing.
PreviousSales wants a `leadScore` field on `Customer` and Billing wants a `taxId` field, and someone proposes one `customers` service with one table holding both. What's the argument against, and what would you build instead?Next A mobile app currently calls eleven different service hosts directly, each with its own certificate and auth flow. What does putting an API gateway in front of them actually buy, and what's the test for whether a piece of logic belongs there?