3,000 m
The architecture
Three questions before you pick
The event versus request-reply debate usually runs on taste. One camp likes Platform Events because they feel modern, the other likes REST because they can watch it work in Postman. Both are right some of the time. The trick is to decide on the properties of the interaction rather than the preferences of the room, and to make the call before the build starts, not in the post-incident review. Three questions, asked honestly, get you most of the way there, and none of them mention technology.
First, does the caller need an answer to carry on? If a user is waiting on a screen for a credit check, that is request-reply, and pretending otherwise just moves the waiting somewhere harder to see. Second, how many parties care about the change? One consumer suggests a call. Several consumers, or consumers you have not met yet, suggest an event. Third, what should happen when the other side is down for an hour? Most teams skip this one, which is why it is the one that matters.
If the honest answer is that the work should queue and catch up, you want events with a durable replay window and a consumer that shrugs off duplicates. If the answer is that the user must be told straight away, you want a synchronous call with a sensible timeout and an error a human can act on. Write the three answers into the design record. Next time the debate starts, point at them and go and get a coffee.
