If the desire is to mostly keep this architecture, the flag in the DB for "has a streaming account linked" needs to not be a boolean, and then you could have a third state besides "Ready to link" and "Link": 'Pending unlink' which would cause the UI to ask the user to stand by until the streaming site confirms the unlinking. Mildly inconvenient for the 0.1% of people who need to unlink just to immediately re-link, but better than buggy.

> From a user experience perspective, the user has no need to wait around until the link is severed. They expressed the intent to sever the link, and were told this would be accomplished. Generally, that's sufficient.

That's incorrect I'm afraid. The reason the flow is synchronous for linking is so that the user can consume the service as soon as they link it. Async means they would have to wait, no user wants to wait.

Similarly, cancellation is asynchronous so that the service doesn't stop immediately. This benegits both the service and the bsnk or credit card company since users often do change their minds and resume the service during the "cool-off" period.

tl;dr, the current logic is correct, it just does not work for your use-case, which is understandably frustrating.

What's everyone's favorite torrent site these days? Mine is Bitsearch, it has absolutely everything