Open a banking app and the home screen loads in a blink. Behind it, one request quietly asks three systems for your account balance, your recent transactions, and the offers you qualify for.
Now think about a loan application. It takes two days. It waits on documents, a credit check and a person's approval, and it must never lose its place if a server restarts.
Both are workflows. They need opposite things.
What "remembering every step" costs
A loan application needs a save point after every step. If something breaks, it resumes right where it stopped. That's the job of a durable workflow engine, and it's worth the price. Saving state takes time, and for a two-day process, nobody notices.
A home screen is different. Nobody is going to resume it tomorrow. The user is staring at a spinner right now, so every millisecond spent writing down "step two finished" is a millisecond they wait for nothing. If the request fails, the app just asks again.
The point isn't that saving state is bad. It's that it should match the job.
What a fast API workflow needs
For the short, user-facing kind, the list is different from a back-office process:
Answers in milliseconds. The person is waiting.
Partial results. Send the balance as soon as it arrives instead of holding everything until the slowest call returns.
Parallel calls. Ask all three systems at once, not one after another.
Security built in. API key authentication and rate limiting, since these calls face the outside world.
Fan-out in practice
Take that home screen. One incoming request fans out: account data from one system, recent transactions from another, current offers from a third. The workflow gathers the three answers, reshapes them into the format the app expects, and returns one response.
Total wait is roughly the slowest of the three calls, not the sum of all three. That's the whole reason to fan out.
So which kind do you have?
Ask two questions. If this fails halfway, does someone need it to resume where it stopped, or can the caller just retry? And how long is a human waiting?
If a failure means money in limbo or a process that has to finish, keep the state. If it's a quick read that someone is watching load, keep it light. Most systems have both kinds, and the mistake is using one setup for everything.
Unmeshed says it's built to handle both: short API-driven flows and long-running backend processes on the same platform.
Top comments (0)