[Leaving this here as comments are closed over there.]
That's a smart and well-documented method and it gets my overall thumbs-up!
Yet I can't help noting there's a problem with it -- as with any solution that relies on making an individual synchronous API call in response to each lead-initiated action -- in that it doesn't take into account the API limits, nor retry/backoff/batching logic in general.
For something as sensitive as unsubscribes, where all your instances' reputations are at stake, I feel that's a risk worth acknowledging. I try to make any operations we do against a resource-governed API (not just Marketo's) use a message queue. For example, knowing we only can do 100 calls every 20 seconds, I would ensure we only pull messages off the queue at a rate slightly below the limit. If we didn't, we could easily have enough IIS/,NET threads running to overwhelm API -side limits. Queueing in turn allows us to batchify our calls so the total volume of lead actions we can service in the time period is much higher. It's also not just about the API side but dealing gracefully with network issues during the POST, or a crashed webserver, etc..
Sure, it seems unlikely that you would be processing such a high rate of unsubscribes. But with the size of some blasts, it's not impossible. And if you send something that results in a high rate of negative feedback (it happens!) those are exactly the unsubscribes you want to be sure to honor, right? Or else you're just digging yourself deeper from a PR standpoint.
Although you can fall back to manual updates when you log errors, feasibility there also depends on volume and having a documented procedure for extracting missed actions from the log.
I'd probably prefer a Subscription Center that interacts with all the instances (only returning "You've been unsubscribed." once the onSuccess has run for all the form posts). That way, the feedback you give to the user is accurate yet the back end doesn't have to get super-complex.
P.S. I know real IT life doesn't reflect my lofty design goals. Our web team -- who may be reading this! -- has yet to queueify most of our SFDC stuff. Under some perfect-storm conditions we will end up getting permanent failures because we can't queue stuff up for later. But I don't have to like it!
.png)