Requirement Gathering is indeed the most cruicial part of building the solution. We could leverage current models to formulate contextual queries to understand problem statements.

So my approach here is simple, 𝑶𝒏𝒆 𝑬𝒗𝒆𝒏𝒕, 𝑶𝒏𝒆 𝑨𝒄𝒕𝒊𝒐𝒏. If there are multiple things to handle, let them happen in idempotent manner and via asynchronous communication channel. This keeps actions safe from duplication and separates concerns from business logic.

Hence multiple edge cases pop up, like what happens if user navigates to a different page after first API call succeed but before second one is fired (assuming they are sequential in nature). And there is no right way of handling these scenarios and many such more.

But as the time goes, applications grow into more complex nuances that does more than one thing at a time. Like clicking on a Button now not only fires an API but also fires another API after that. This is an anti-pattern as these calls are asynchronous in nature and user is not expecting as such.