DEV Community: The Unmeshed Team

How We Reduced Our LLM Token Bill by 80% Without Downgrading the Model

The Unmeshed Team — Tue, 11 Aug 2026 06:27:33 +0000

Let’s make it Agentic!

The push in the market is to use agentic flows. Agentic is when you let a model decide how to process a request or a flow and expect its abilities to parse and understand context to result in the best possible outcome for the use case. The idea is that as models mature and become more “intelligent” the outcomes become more high quality and beats a human coded fixed algorithm.

With this in mind, oftentimes you’d see a use case pushed into production which relies on model calls completely.

For example, an agent may execute a use case by parsing input, validating data, classifying the request, checking policy, routing it to the right person, and drafting a response, all by calling a model.

It's often quite fast to build this, with the many agentic frameworks out there today and the demo is usually great and impressive to the management.

Launching this in production in a high volume use case will bring a shock though - when the bill arrives from the model providers. Token costs are increasing rather than decreasing as models evolve. Now is that use case adding sufficient value to the cost of running it?

What about questions such as consistency, latency, security and governance? And an even bigger question, do you really know why a decision was made?

I think there is a trend shift happening now in the market. The shift is to double check token spend to value creation. This shift is primarily among those who have already shipped a reasonable amount of use cases leveraging AI. The camp that is still working to deploy some use cases is not bothered by the spend yet as it hasn’t really hit them yet. But it's almost a certainty that once your budget starts to get eaten up, the question will come.

Going to Production with AI

The instinct to use AI for everything was not wrong. But does it always make sense? Teams and people are starting to ask which of the steps actually needs “intelligence” and which ones just need some rules or logic? This leads to answers for not just token spend, but the latency and consistency as well. Consistency means you know the reasons why the system is doing something.

But if we are not using AI, are we not losing out? Isn’t that what everyone says now? Get onboard or be left behind to be eaten by more modern competing companies.

The solution is to maximize the use of AI, but in a way that it yields maximum value and not just blindly at everything. I think an example is overdue for explaining this.

Expense approvals - This is quite common and every company needs it and typically it's done by a couple methods:

A human manually reviews and approves each expense based on some published policy
Some rules in a HR system that can automatically approve some expenses and route others to approvers

Let’s say the finance team of a company wants to be more dynamic, rapidly respond to changing trends and create a system that can benefit the company to maximize employee productivity - by letting them manage expenses that are not bound by rules set in stone!

An engineering team asked to build this could simply do this - ask the finance team to write the policy in a Google Doc or something - which can then be published to the internal portal as the official policy and then say build an AI agent that reads this policy and approves every request based on the policy. Now the finance team can update the policy every now and then, and without any developer in the loop, the policy can reflect on each expense approval request - Et Voila! Cool right?

Steps:

User initiate a chat with an expense agent
Exchange greetings (of course we humans always do that, agent or not!)
Upload a receipt, explain the expense
Agent parses the receipt, validates the amounts and dates
Evaluates the entire expense policy against the request
Decides on the request, informs the user
If approved, make a request to the HR system to note the required expense reimbursement

This is a pretty cool agentic flow if you were to build it and I think the finance team and the entire company is probably going to be thrilled to use it. First, policies will start being practically applied (assuming the AI is intelligent) and the finance team has the flexibility to change it every Monday if they want to. Win win - And the CTO can present to the board on how they leveraged the intelligence of the models available today to add value to the business.

The big savings here is the manual approval times that the finance team would have to spend on without something like this. Or even more is the developer time required to keep changing policies as they change and lead time for doing so while expenses may not be processed as per the latest update.

So is this value worth the new token bills that may now start coming from the model providers?

Optimizing the AI

What could we do differently here? The models are worthy of use for sure. It's proven beyond doubt that it can be very effective in a lot of scenarios. A change up for the example above could be this:

On every policy update, steps:

Read the latest policy
Create a set of rules for basic cases extracted from the policy
Create test scenarios for the human to verify
Send the test scenarios and ruleset for finance team to approve
Deploy rules into production

On every expense request, steps:

Present a data entry form for user
- If user chooses to enter via an unstructured form, then run the model to convert it into structured
Run the rules deployed
- if its matching, approve or deny as per rules
- If none matches
- Run the model to decide approval
- Or route to human for the lower volume
Inform the user and invoke the HR system for reimbursement

Still using that model! But only where it matters and you can pretty much cut down the token costs by 80-90%. The more people who use structured input, there is not even a need for the model to parse the inputs. We still end up the model’s intelligence but in a more consistent way since it created static, deterministic rules. The large volume of requests will be now automatically approved by the updated rulesets for each policy update by the finance team. Same flexibility as the earlier flow, but with a lot lower token spend. And we get to use AI to do the one thing it's designed to do great - code things out! A developer in the loop can also review the code and ensure its consistent with the engineering standards just like any other code review. Win win win across the board.

Judgment vs. logic

It’s quite easy to decide when you need a model and when you need a simple logical interpretation. In every workflow step decide on this:

Does this step require understanding context, generating language, or making a nuanced decision, or does it just need to follow a rule?

It is a useful question because it removes some of the glamour from the architecture. Most steps, when you ask it honestly, are less mysterious than they first looked.

Steps that need judgment	Steps that need logic
Classifying ambiguous or unstructured input	Routing based on a known field value
Summarizing a document or conversation	Validating a number against a threshold
Generating a policy, workflow, or config	Running a decision table at scale
Explaining a rejection in plain English	Parsing a structured form submission
Helping a non-technical user set up a rule	Executing that rule 50,000 times a day

About our platform - Unmeshed

So since you are reading this - I’d love to share a bit about our platform - Unmeshed. Unmeshed helps teams build AI-powered workflows that combine model calls, deterministic rules, API integrations, human approvals, and observability in one place.

In Unmeshed, engineering teams can:

Model API calls, rules, decision tables, human approvals, and AI steps in one workflow
See which steps call models and why
Attribute cost to specific workflows and outcomes
Put budgets, scopes, and tool allow-lists around agentic execution
Keep humans in the loop for high-risk or ambiguous decisions
Move repeatable decisions from model calls into deterministic logic over time

The decision table is a rules engine and you can create complex business rules using AI or manually. This is where you could use models to create your rules, have humans validate them and then run them for effectively next to nothing compared to individual model calls for every use case execution.

If your team is adding AI into business processes and starting to ask where the cost, latency, and outcomes are coming from, Unmeshed gives you one place to design, run, observe, and optimize the workflow.

Still routing everything through a model?

Cut token spend without cutting capability

Unmeshed combines AI steps, decision tables, and human approval in one workflow, so repeatable decisions run as rules instead of expensive model calls.
Try Unmeshed or Talk to us

Building a Smart Drip Email Funnel That Knows When to Stop

The Unmeshed Team — Mon, 10 Aug 2026 06:31:36 +0000

Shipping a SaaS is the easy part now. You put up a landing page, open a free trial, and signups start showing up.

What happens after the signup is where things get messy.

You've got people sitting inside a 14-day trial. You don't know who's using the product, who's silently giving up on it, or who paid yesterday. You meant to email them on Day 3. Then Day 7. You forgot. Or worse: you remembered, and sent a "trial ends tomorrow" reminder to someone who upgraded two days ago.

Small things, but they add up. A funnel that does this badly is barely better than no funnel at all.

So I built one in Unmeshed.

Five emails over fourteen days, on Day 0, 3, 7, 11, and 13. Before every send after Day 0, the workflow hits your API and checks if the user has upgraded. If they have, it exits and logs the conversion. No "last chance" emails to paying customers.

Emails go out through Gmail. Sends and conversions get appended to a Google Sheet, which ends up being a perfectly fine lightweight CRM once you have a few rows in it.

Want to try this exact flow? Open the SaaS Trial Onboarding template and adapt it to your trial funnel.

Most trial funnels fail the same two ways

Either nothing goes out, because the founder is busy shipping and Day 3 quietly turns into Day 9. Or a cron job blasts the full sequence regardless of who's converted, churned, or moved on.

Both leak revenue, and both feel sloppy to the user on the receiving end.

A funnel that actually works has to do three things. Reach people at the right moments. Stop the moment someone upgrades. And leave a trail so you can look at what happened later.

The third one is what most setups skip, and it's the reason most founders have no idea where their funnel actually leaks.

Walking through it

I'll use a fake SaaS called Stagepad for the examples. Pretend it's a hosted staging environment tool for solo devs. The shape works for anything on a 14-day trial.

1. Trigger and trial window

The workflow fires when someone signs up. It gets two fields:


{

  "userEmail": "alex@example.com",

  "userName": "Alex"

}

The first step is a tiny JavaScript step that calculates the trial end date (today plus 14 days) and formats it into something readable, like Thursday, June 12th. Every email in the funnel references this date, so the user always sees the same concrete deadline instead of a vague "your trial is ending soon."

2. Day 0: Welcome

The welcome email goes out right away. It covers what they get on the trial, what to expect over the next two weeks, and the trial end date.

Two things happen in the background after the send: the timestamp gets captured, and a row gets appended to the tracker sheet with the user's email, name, trial end date, Day 0 send time, and in_progress as the status. From here on, the sheet has one row per trial user, and the row keeps getting updated as the funnel moves forward.

3. Wait, then check before sending

Here's the part that makes it honest.

Every send after Day 0 follows the same three steps. Wait until the right day. Hit the upgrade-status API. Branch on the result.

The wait is a native Unmeshed WAIT step. No cron, no external scheduler, nothing fragile sitting on your laptop. The workflow pauses for 72 hours, then 96, then 96 again, then 48.

The upgrade check is a plain GET to your own API:


GET https://api.stagepad.com/v1/users/upgrade-status?email=alex@example.com

Authorization: Bearer ...

Your API returns { "subscribed": true } or { "subscribed": false }. A SWITCH step reads it:


(steps, context) => {

  const subscribed =

    steps.check_upgrade_day3.output.response &&

    steps.check_upgrade_day3.output.response.subscribed === true;


  return subscribed ? "subscribed" : "not_subscribed";

};

If they subscribed, the workflow logs converted_before_day3 with a timestamp and exits. If not, the email goes out and the send gets logged.

That gate runs again before Day 7, Day 11, and Day 13. Four chances to catch a conversion before sending the wrong email.

4. The five emails

Quick summary of what each one is doing:

Day 0, Welcome. Trial access, what to expect.
Day 3, Value tip. A specific action that gets them a real result from the product. Hints at what paid unlocks.
Day 7, Mid-trial highlight. One strong paid feature and the problem it solves.
Day 11, Soft nudge. Three days left, what they keep on the paid plan. No urgency theatrics.
Day 13, Last chance. Trial ends tomorrow. Honest framing: if the product has been useful, here's the upgrade link; if not, no hard feelings.

Every email references the trial end date from Step 1, so the deadline stays specific.

5. The tracker sheet

Every send appends a row. Conversions append a row too, with an Upgraded At timestamp and an exit reason like converted_before_day7.

After a few weeks the sheet starts being useful on its own. You can see who's at what stage, when emails went out, where conversions tend to land (Day 3? Day 11? After Day 13?), and which users went completely silent.

No Mixpanel. No HubSpot. A sheet you can open.

One more thing: setup is a workflow too

The tracker sheet itself gets created by a separate one-time workflow.

You run create-trial-tracker-sheet once. It creates a sheet titled SaaS Trial Tracker, writes the header row across twelve columns (Email, Name, Trial End Date, the five send timestamps, Upgraded, Upgraded At, Exit Reason, Workflow Run ID), and returns the spreadsheet ID and URL.

Paste the ID into the main funnel workflow as variables.tracker_sheet_id and you're done. Setup isn't a README full of clicks, it's a workflow you run once.

What this replaces

For a solo dev or a small team, this usually takes the place of:

A calendar reminder to email trial users that you'll forget
A Mailchimp or Customer.io account you started configuring six months ago and never finished
A setTimeout-based scheduler in your backend that breaks every time you deploy
Nothing, which is the most common option and the most expensive one

What separates this from a generic drip tool is the upgrade check. Most email tools can send on a schedule. Stopping cleanly when someone converts usually means webhooks, audience syncing, and glue code you'll have to maintain. Here it's one HTTP call and one switch per email.

Closing

A trial funnel sounds small until you start writing one.

Five emails over fourteen days isn't much code. But once you add "stop if they upgrade," "log every send," "remember each user's trial end date," and "survive me closing the laptop for the weekend," it stops being a weekend project.

Define it once as a workflow and Unmeshed handles the waiting, the branching, and the logging. You go back to building the product.

Turn your trial funnel into a real workflow

If your trial emails are spread across a calendar, a half-configured email tool, and a few cron jobs you're afraid to touch, Unmeshed gives you one place to define and run the whole sequence, including the part where it stops at the right time.
Try Unmeshed or Talk to us
Bring your own onboarding, trial, or lifecycle flow and we can help you shape it.

Stop Redeploying Your Entire Backend Just to Fix a Single Validation Bug

The Unmeshed Team — Fri, 07 Aug 2026 05:14:36 +0000

Modern backend systems often become complex, and every code change or deployment can feel like a potential risk for downtime. With Unmeshed, your backend logic is managed as modular workflows, so you can build, monitor, and update business processes visually without touching your application code.

Fix Issues Instantly Without Deployment Nightmares

When something breaks in your backend, you do not need to redeploy or hotfix your codebase. Instead, you update or fix the specific step in your Unmeshed workflow. This means:

Minimal downtime because fixes are instant and isolated
No risky code rollbacks or emergency redeploys
Business operations keep running smoothly

Teams can monitor, debug, and patch workflows live, so you avoid the classic deployment nightmare.

Example: Order Processing Workflow

Let's say your order processing backend is a workflow:

Validate Order
Process Payment
Update Inventory
Send Confirmation

If Process Payment fails, you just fix or update that step in the workflow. No code change, no redeploy, and your business is back online in minutes.

You can build similar workflows for user onboarding, data sync, or any business process, knowing that if a step breaks, you can fix it instantly without deployment drama.

Buggy Script vs Fixed Script: Why Validation Matters

Let's look at a real-world example of how a missing validation can cause issues, and how Unmeshed makes it easy to fix bugs like this instantly, without redeployment.

Buggy Script

(steps, context) => {
  // No validation (BUG)
  const txnAmount = context.input.txnAmount;
  const orderId = context.input.orderId;
  return {
      success: true
  };
}

Problem: No validation on txnAmount. Invalid or negative values can slip through, causing silent failures and cascading errors downstream.

Fixed Script

// Validation rules: 1. Must be a number 2. Must be greater than 0

(steps, context) => {
  const txnAmount = Number(context.input.txnAmount);
  const orderId = context.input.orderId;
  // Validate txnAmount
  if (isNaN(txnAmount) || txnAmount <= 0) {
    throw new Error("Invalid txnAmount. It must be a positive number.");
  }
  return {
    success: true,
  };
}

Fix: Now txnAmount is validated before processing. Invalid data is caught immediately and rejected safely.

The Unmeshed Advantage

With traditional deployments, fixing the buggy script requires:

Changing the code
Testing it
Creating a PR
Code review
Merging to main
Redeploying the entire service

Risk: If something goes wrong in the redeployment, your entire order processing system could go down.

With Unmeshed, you simply:

Edit the step in your Unmeshed workflow
Click Save

Result: The fix is live immediately, the rest of your workflow is untouched, and order processing continues seamlessly.

Unmeshed empowers engineering teams to move fast without fear of deployment downtime. Host your workflows with Unmeshed and experience stress-free releases.

API Composition with Unmeshed: One Endpoint, Many Systems

The Unmeshed Team — Thu, 06 Aug 2026 06:06:53 +0000

At some point in every backend's life, there's an endpoint that looks simple on the outside and is a disaster on the inside.

One route. One URL. But behind it: four service calls, a retry loop for the billing API that goes down every other Tuesday, conditional logic depending on account status, parallel fetches to reduce latency, and a response-shaping step that glues it all into something the frontend can actually use.

The handler started at 40 lines. Now it's 400. Two engineers have already said "we should really clean this up" and moved on to something more urgent. And every time product changes a rule, someone has to spelunk through the handler, figure out where the branching is, hope the tests catch any regressions, and push it out.

This is not a code quality problem. It is an architectural one. The endpoint is doing orchestration work, but it is living in a place that was never designed to hold orchestration.

Unmeshed is built specifically for this situation. The workflow becomes the execution layer behind the endpoint: explicit, visible, and designed to coordinate across systems.

The endpoint is not the hard part

The route itself is trivial. Five lines. Register the path, parse the input, return the response.

The hard part is what the route has to do:

validate the incoming request against a contract
call internal services that may or may not be available
run independent lookups in parallel because sequential calls are too slow
apply business rules that have changed three times this year
retry dependencies that fail transiently
fall back gracefully when one system is unavailable
shape four different service responses into one coherent payload
Once an endpoint is doing all of that, HTTP is almost incidental. The real work is coordination.

That coordination is exactly what a workflow engine is designed to carry. The problem is that most teams never move it there. They just keep growing the handler until it becomes the most complex, least understood part of the backend.

What this actually looks like

Here is a real-world example of the kind of endpoint that gets into trouble fast.

A frontend dashboard, a partner integration, or an internal tool needs one call that returns a unified customer view. Something like:

GET /customer/360?customerId=cus_123

The caller does not want to make five requests and stitch the answer together. It wants one response: profile, subscription state, recent orders, open support tickets.

Behind that single request, the backend has to coordinate validation, parallel service calls, retry logic, fallback behavior, business rules, and response shaping.

Left: retries, fallbacks, and parallel fetches buried inside a single route handler. Right: the same steps as an explicit Unmeshed workflow, named, ordered, and visible.

None of that is especially exotic. But all of it living inside a route handler is the slow-motion version of a bad day.

The retry logic for billing sits next to the response shaping. The fallback for the support system is buried three levels deep in an if-block. The parallel fetch is a Promise.all that someone added six months ago, and nobody is fully sure what happens if one of the promises rejects.

When something goes wrong in production, and something always goes wrong, the debugging process is: check logs across four services, hope the correlation IDs were propagated, piece together a timeline, and pray the failure was in a path that actually has logging.

What changes when the workflow is the execution layer

With Unmeshed, the endpoint becomes the entry point. The workflow owns the coordination.

The caller still makes one request to one URL. But the steps, the branching, the retries, the parallel execution: all of that lives inside an explicit workflow definition instead of being scattered across the handler and its dependencies.

Your services still own their domains. The profile service still owns profile data. Billing still owns subscription state. The support platform still owns tickets. What moves out of the handler is the logic that coordinates between them.

That separation matters more than it might sound. It means:

The coordination logic is visible. Instead of reconstructing what the handler does by reading code, you can see the execution graph directly. Which steps ran. Which step failed. Which branch was taken. What retried, and whether it succeeded.

Failures are easier to reason about. When billing is unavailable, the retry policy is defined in the workflow, not implied by a try-catch somewhere in the handler. When the support system is down, the fallback behavior is explicit, not dependent on whether a developer remembered to handle that case.

Changes are scoped. When product changes the flagging rule for accounts with failed payments, that change lives in the workflow step that applies business rules, not threaded through a handler that also happens to be responsible for parallel fetches and response shaping.

The response contract stays stable. The caller gets one clean shape regardless of how many systems participate behind the scenes.

{
  "customerId": "cus_123",
  "profile": {
    "name": "Ava Johnson",
    "email": "ava@northfield.io"
  },
  "subscription": {
    "plan": "growth",
    "status": "active"
  },
  "recentOrders": 4,
  "openTickets": 1,
  "flags": ["payment_review"]
}

The frontend does not need to understand your internal architecture. It needs a stable shape. The workflow guarantees that shape regardless of which dependencies had a bad day.

Calling it looks like any other API

This is not a special invocation model. From the caller's perspective, it is a normal endpoint.

curl -X GET "https://your-unmeshed-endpoint/customer/360?customerId=cus_123"

Or as a POST with a structured body:

{
  "customerId": "cus_123",
  "includeOrders": true,
  "includeSupport": true
}

The caller sees one endpoint, one stable contract, one response. The fact that the execution layer is a workflow instead of a handler is an implementation detail, but it's the implementation detail that makes the whole thing maintainable.

Not every endpoint needs to block

One more thing worth making explicit: the workflow-as-endpoint pattern works for both synchronous and asynchronous flows.

Some endpoints need to return a completed response immediately. The customer 360 example is synchronous: the caller is waiting. Eligibility checks, pricing calculations, BFF aggregation endpoints, all of these are cases where the caller needs the answer before it can do anything else.

Other endpoints just need to confirm that a process has started. Onboarding flows, document processing, approval workflows, signup qualification: these are cases where the backend kicks off work that continues after the response. The caller gets a confirmation while the workflow continues in the background.

In both cases, Unmeshed owns the coordination. The endpoint is the entry point. The difference is just whether the caller waits for the result or not.

Which endpoints actually benefit from this

Not every endpoint needs orchestration. If a route is a thin pass-through to one service, adding a workflow layer is unnecessary overhead.

But for endpoints that are already doing real coordination work, the workflow model is almost always cleaner than the alternative. Good candidates:

BFF endpoints that aggregate data from multiple services before returning to a client
Partner-facing APIs that need a stable response contract regardless of backend changes
Internal APIs that coordinate business rules across teams or systems
Any endpoint where retries, fallbacks, and branching logic have started accumulating in the handler
If an endpoint has ever made you think "I'm not sure exactly what this does anymore," it is probably a workflow that has not been given a proper place to live.

The real question

Most teams do not make an active decision to grow orchestration logic inside route handlers. It just happens, one added dependency at a time, one edge case at a time, until the endpoint is doing work that was never supposed to be its job.

The question is not whether to have orchestration. You already have it. The question is whether it stays buried in handlers and helper modules, or lives somewhere designed to coordinate it explicitly.

For endpoints doing real orchestration work, Unmeshed gives that logic a place designed to hold it: visible, manageable, and built for the kind of multi-system coordination that makes route handlers hard to live with over time.

Build backend flows that stay manageable

If your backend endpoints are coordinating multiple systems, applying branching rules, and triggering follow-up work, Unmeshed gives that logic a cleaner place to run.
Try Unmeshed or Talk to us
Bring an endpoint or backend flow that has gotten harder to maintain than it should be.

From Netflix Conductor to Unmeshed: How Microservice Orchestration Evolved

The Unmeshed Team — Wed, 05 Aug 2026 05:38:57 +0000

In the early 2000s, monolithic software architectures dominated but were limited by scalability and prone to outages. The emergence of cloud computing and microservice orchestration revolutionized distributed systems, enabling greater agility and reliability. Netflix pioneered this shift, laying the foundation for modern API orchestration, and today platforms like Unmeshed are taking this even further.

Monolithic Software to Cloud Agility in Microservice Orchestration

Early tech platforms were like overloaded large heavy backpacks (monolithic servers) and struggled to scale with user growth. Cloud computing was a game-changer. Imagine ditching a big backpack for a rolling expandable suitcase – flexible, scalable servers offered by services like AWS. Netflix saw the value and went all-in, handling their streaming boom with ease. Cloud computing offered not just scaling, but also reliability. Distributed resources meant fewer crashes or lengthy outages. And companies were able to scale to meet customer demands.

Cloud Computing and Microservices: How Netflix Revolutionized API & Microservices Orchestration

The rise of cloud computing exposed the limitations of monolithic software. Cloud providers like AWS, Azure, and GCP revolutionized the industry by offering on-demand infrastructure and the ability to build and deploy software rapidly. To leverage these providers, companies shifted towards microservices, breaking down monoliths into smaller, manageable services. These services, managed by small teams, led to a modular and flexible architecture that could scale effortlessly.

However, the microservices boom introduced new challenges, particularly in managing distributed systems. Simple tasks evolved into complex coordination issues. At the forefront of this transformation, Netflix pioneered solutions with homegrown tools such as Service Discovery and Orchestration. Netflix Conductor emerged as a great solution for managing microservices.

Conductor: Orchestrating the Future of Streaming (and Beyond)

Netflix's growth exposed a critical need for agility – a need that traditional monolithic systems couldn't meet. With Conductor, designed to seamlessly integrate with existing systems (brownfield applications) and agnostic to programming languages, Conductor empowered Netflix developers to move fast. Recognizing its broader potential, Netflix open-sourced it and today, Conductor's language-agnostic and cloud-neutral design make it the go-to solution for microservice orchestration across industries.

unmeshing the Future: Conductor's Legacy Lives On

While Conductor has successfully served a wide range of use cases, the need for evolution became evident. This realization led us to create unmeshed, a next-generation platform designed to address the scale and needs of modern developers. Today's systems are increasingly about integrating various systems seamlessly. Spearheaded by a founding team member of Netflix Conductor, unmeshed aims to be the ultimate, highly reliable orchestration and integration platform. Built by developers for developers.

Code vs Config for API Orchestration: A Practical Breakdown

The Unmeshed Team — Tue, 04 Aug 2026 05:17:58 +0000

One interesting perspective I often hear about workflows is how approaching
them with configuration is better than with code, or the opposite, depending
on who you're talking to.

Many established products in the workflow orchestration space claim it's
easier to write workflows as code. The biggest argument in favor of this is
that complexity is better addressed in code compared to a configuration or
DSL. This comes with the assumption that workflows will be where the logic
lives.

My personal take is that this anticipated complexity doesn't really exist.
The moment your code leaves the boundary of a single method, you're already
orchestrating outside of your code. And you end up building a deeply
coupled, hard-to-maintain system when the orchestration leaves your library
boundary to another app or service.

Code as Building Blocks

A building-blocks code model, interconnected only via orchestration, gives
you cleaner, more testable, and maintainable code, and lets you retain a
simpler, maintainable architecture. Remember: you're still writing code —
you're just wiring things up using orchestration.

This is evident in how some of us use event-driven choreography. The entire
idea is to decouple and run services that aren't aware of each other. The
events being routed from one place to another don't have complexity that
can be resolved with code.

However, the challenge with choreography is the lack of visibility into how
things map. This is where the power of orchestration comes through.

Code vs Configuration

The topic of this debate is moot, because it's really your code that's
being orchestrated. It would make less sense to orchestrate within code.
Instead, the code you write should be orchestrated to create the flows that
meet your goals — while keeping things cleanly decoupled, unmeshed.

What are your thoughts on this? Is it time to unmesh your workflow
complexity from code?

Who’s Actually in Control When Everything Breaks at Once?

The Unmeshed Team — Mon, 03 Aug 2026 05:30:10 +0000

Orchestration Platforms: Gaining control in the face of chaos

As an engineering lead for an e-commerce platform, imagine it’s Black Friday—your system is under an unprecedented load, orders are flying in from across the globe, and your services are being pushed to their limits. You’ve got a complex web of systems to manage.

It’s a highly interconnected and distributed environment, and with this level of complexity, even a minor failure can create cascading issues that jeopardize the entire operation. This is where an orchestration platform—or, to use a fitting analogy, a ringmaster—comes into play.

How an Orchestration Platform Handles the Complexity

An orchestration platform ensures that every component in this highly distributed environment interacts smoothly. Here’s how:

Service Coordination and Workflow Automation

In complex architectures, services often rely on each other to complete a workflow. For instance, before shipping an order, the system needs to verify inventory, process the payment, and generate a shipping label—all while ensuring no single point of failure disrupts the flow. The orchestration platform automatically coordinates the workflows by handling service-to-service communication, retrying failed tasks, and ensuring each service operates in the correct sequence.

Error Handling and Fault tolerance

Even in the best-engineered systems, things break—an API call might time out, a database query might fail, or a service could crash under load. Without a centralized platform to manage these failures, developers would have to build custom error-handling mechanisms for every service interaction, increasing the complexity of the codebase. This needs not be the case. If the payment gateway is temporarily unavailable, the platform can queue orders for later processing, ensuring the order system continues to function without a complete halt.

Scaling and Load Management

Through horizontal scaling, orchestration platform spins up additional instances of services to handle increased demand, while load balancers distribute traﬃc evenly across these instances. This ensures that no single service becomes a bottleneck. During peak traﬃc, the orchestration platform can automatically scale up your payment processing service or spin up additional AI model instances to keep up with the demand for personalized recommendations.

Real-Time Monitoring and Observability

Visibility into system performance is critical for preventing downtime. Orchestration platforms provide real-time monitoring, allowing engineering teams to track the status of workflows, measure performance, and detect bottlenecks or failures before they impact the customer experience. If one service in your workflow starts lagging—say, the AI recommendation model—the platform’s monitoring tools will alert you to the issue, allowing you to address it before it affects the customer experience.

Handling Complex Business Logic

Modern e-commerce systems often require custom business rules for processing orders, handling refunds, managing stock levels, or even implementing fraud detection. These rules may change frequently and can vary based on the region, customer type, or order size. Orchestration platforms make it easy to implement and modify these rules without having to refactor the underlying codebase for each service. You can define custom workflows to handle these scenarios in the orchestration layer.

Final Thoughts: Unmeshed as the Ringmaster of Your System

Without a ringmaster, managing an e-commerce platform’s complex infrastructure on a high-traffic day like Black Friday would be overwhelming. By integrating orchestration platform into your architecture, it provides the orchestration layer necessary to manage workflows, handle errors, and scale your systems gracefully, ensuring everything runs seamlessly—even when the unexpected happens. For engineering teams dealing with complex distributed systems, investing in an orchestration platform is a game-changer. It’s the difference between a chaotic circus and a perfectly synchronized show, where every component plays its part flawlessly.

Stop Building "Black-Box" Microservices: How Workflow Orchestration Saves Developer Time

The Unmeshed Team — Fri, 31 Jul 2026 05:33:02 +0000

Introduction

Everyday, between coffee breaks (maybe tea?), we click on tech news in search of some technology breakthroughs that are somewhat relevant to us and hopefully, transform the quality of our work and supercharge productivity. My question to you is, have you found anything that makes a direct impact on your productivity? The truth is, in today’s fast-paced digital landscape, businesses need to innovate quickly and operate efficiently to stay competitive, and developers are responsible for carrying out the implementation.

My take is that an orchestration platforms have become such an invaluable tool in achieving these goals, transforming how companies manage complex workflows and streamline integrations, and this is a clear sign that you, the developer, will benefit because you will see massive time saved from all sort of mundane tasks and focus on what really matters to you and your team. From automating intricate processes to visualizing workflows and simplifying system integrations, orchestration is at the heart of driving efficiency and enabling rapid innovation.

Here, we’ll explore the top 5 ways orchestration platforms empower businesses to boost productivity, accelerate development, and bring impactful ideas to market faster.

Automating Complex Flows: Boosting Efficiency in Technical and Business Processes

Orchestration platforms simplify the automation of intricate workflows, from handling backend data processes to customer-facing business flows. These tools can handle both long-running (subjected to technical challenges) and short-running tasks (surge in volume), ensuring that every workflow is fully managed and optimized.

For example, an orchestration platform enables stock-trading logs that span several hours and involve various data-sensitive components or coordinate real-time order processing for a trading firm. Automating these flows reduces manual errors, accelerates task completion, and enables a seamless, end-to-end process.

Accelerate Go-to-Market with Fast Prototyping and Experimentation

Another key feature of orchestration is that it allows teams to quickly assemble and deploy proof-of-concept workflows, enabling rapid testing and iteration in live environments. This fast-tracks the process of moving from an idea to a production-ready solution.

Your deployment team will have peace of mind deploying with the integration of the orchestration platform, allowing processing errors to be detected and handled immediately, through the end-to-end process visualization, essentially eliminating ‘black-box’ scenarios like it’s a thing of the past.

By making it easy to assemble creative workflows and persistent state management, businesses can explore innovative concepts and observe their impact in real time, reducing the time it takes to refine and launch new features. This “learn-by-doing” approach is essential for agile development cycles, especially for teams looking to try out cutting-edge ideas or disruptive changes.

Visualizing Workflows: Enhancing Clarity and Transparency

With orchestration, workflows are no longer “black box” business processes. Each loosely coupled component is visually represented by process flows, displaying each step’s logical sequence and dependencies. These visualizations help teams quickly understand and communicate the workflow structure, akin to the original design diagrams.

This approach aligns team members, provides documentation for stakeholders, and improves troubleshooting by showing where each action takes place within the flow.

Simplified System Integrations: Bridging Internal and External Systems Seamlessly

In addition, an orchestration platform provides visibility into integrations across internal and external systems, making it easy to see where different applications and data points connect.

For example, consider a hospital that uses an orchestration platform to manage patient data across multiple systems. When a doctor orders lab work, the orchestration platform automatically coordinates the order with an external lab system, retrieves the results, and updates the EHR in real-time. The platform also integrates with the hospital's billing softwasre to automatically generate invoices for services rendered. With the orchestration platform’s visibility, the maintenance team can easily see where each data transfer occurs, identify any integration issues (e.g., delays in data retrieval from the lab), and troubleshoot accordingly.

This transparency not only ensures seamless data flow across different systems but also helps the hospital maintain accurate billing and compliance. Additionally, by understanding these touchpoints, the deployment teams can optimize workflows, improve system reliability, and reduce manual intervention, which is crucial in a healthcare environment where accuracy and efficiency are paramount.

Accelerated Development with Reduced Code Complexity

While there are ongoing debates on the level of participation of humans (also known as human tasks) in workflow management, there is no denial that incorporating human tasks within complex workflows managed by an orchestration platform brings a powerful layer of flexibility and decision-making to automated processes.

Orchestration platforms let engineers build powerful workflows with minimal code, allowing teams to deliver complex functionality quickly. This reduction in code complexity not only shortens development time but also makes maintenance and scaling more manageable.

Teams can spend less time on repetitive coding tasks and focus more on building value-added features, innovation, and reliability. Additionally, orchestration platforms enable modular design, allowing parts of a workflow to be swapped out easily, facilitating faster adoption of new technologies like AI, and machine learning.

My point is…

Orchestration isn’t just a tool—it’s a catalyst for change and growth. By automating workflows, enhancing visibility, and enabling agile development, orchestration platforms allow businesses to focus more on innovation and less on technical overhead.

The result? Faster go-to-market times, improved operational efficiency, and a technology stack that’s primed for future advancements. Embracing orchestration equips businesses with the agility to evolve in a dynamic environment, empowering teams to build, adapt, and grow with confidence.

If you are interested to know more about how an orchestration platform supercharges your productivity and results in massive saving on business cost, drop us an email at contact@unmeshed.io for a demo.

What a Truly API-Native Orchestration Platform Looks Like

The Unmeshed Team — Thu, 30 Jul 2026 05:53:32 +0000

Imagine this: you’re driving and suddenly get lost. Your eager passengers jump in to help. One of them, feeling nostalgic, insists on using a paper map to find the way. Meanwhile, another passenger does what most of us do today—checks Google Maps to quickly find the fastest route to your destination. You might be thinking, come on! Who is still using paper maps today?! Yes, this might sound like a far-fetched example. Both paper maps and Google Maps aim to serve the same purpose: getting you to your destination. But wouldn’t you agree that sometimes we stick to using tools that no longer meet our needs as effectively as they once did?

In this post, we’ll explore why traditional orchestration solutions struggle with API use cases and how Unmeshed—a new-generation orchestration platform—steps in to bridge these gaps effectively. APIs are at the heart of digital innovation, it enables seamless data exchange, it ensures real-time user interactions and handles service integrations across various systems. However, handling API workflows effectively requires an orchestration platform that meets very specific demands.

Why Traditional Orchestration Platforms Struggle with APIs

Most traditional orchestration platforms were designed for a very different set of goals: it manages complex and long-running workflows that span multiple systems and involves robust state management and error handling. While these capabilities are essential for backend processes, they perform less than ideal when applied to the high-speed demands of real-time API orchestration.

Traditional Platforms Prioritize Reliability Over Speed

For example, a platform like Netflix Conductor are open-source orchestration solutions that handle complex, multi-step workflows. Their core purpose is to reliably store and manage the states of each workflow step, ensuring that processes complete successfully—even in the face of failures.

This approach makes Conductor an excellent option for backend orchestration, where stability is the primary requirement. However, when it comes to APIs, this state-heavy, reliability-focused model leads to increased latency. Essentially, APIs demand near-zero response times, a traditional platform and need time to store and track each step, that adds unnecessary delay thus making them unsuitable for low-latency API calls.

Real-Time Needs Aren’t a Design Priority

Bear in mind that API use cases typically require response times measured in milliseconds, as well as the ability to stream partial content and handle thousands of requests per second.

To support these needs, an orchestration platform must prioritize speed and lightweight processing over extensive state tracking. Unfortunately, this demand is often in direct conflict with the design principles of traditional platforms, which prioritize reliability over real-time performance.

Complex State Management is Unnecessary for APIs

In API orchestration, the goal is often to quickly query backend systems, transform data, and return a response. In fact, a complex state management between steps is generally unnecessary and counterproductive for APIscenarios, as it only adds to the processing overhead.

Traditional platforms’ is built to treat every step as a stateful operation that needs to be recorded, managed, and monitored, but this approach isn’t well-suited for the quick, stateless nature of most API workflows.

Key Requirements for an Effective API Orchestration Platform

In response to limitations by traditional orchestration platforms, a dynamic orchestration platform must meet a set of unique requirements that prioritize speed, security, and efficiency, while continuing to be reliable in all scenarios.

Fast Response Times:

APIs need to deliver data at near-instant speeds, often within milliseconds, to maintain a seamless user experience.

Ability to Stream Partial Content:

In some cases, APIs may need to begin delivering content before all data is retrieved. The ability to stream partial results as they're available can dramatically improve the perceived speed of API responses and enhance user experience.

Near-Zero Latency:

APIs power real-time interactions, meaning they must operate with as little latency as possible.

Authentication, Rate Limiting, and Security:

APIs often handle sensitive data, making robust security measures such as API key authentication and rate limiting critical.

How Unmeshed Bridges the Gap

In Unmeshed, we redefined orchestration to support both API and backend scenarios, by creating a unique solution that’s as effective for high-speed API workflows as it is for complex, long-running backend processes. Unmeshed combines the stability of traditional orchestration with the speed and efficiency needed for API management.

Built for Multiple Scenarios

Unmeshed’s architecture was designed to handle the high-speed, low-latency requirements of API orchestration while retaining the capabilities necessary for backend workflows. It is flexible enough to handle both API-driven, short-lived processes and long-running orchestration scenarios, making it a versatile choice for a variety of use cases.

Optimized for Latency and Speed

For APIs, where latency and speed are critical, Unmeshed operates with near-zero latency. Unlike traditional platforms, Unmeshed doesn’t over-rely on complex state management, reducing unnecessary delays. This approach means that API calls are orchestrated efficiently, allowing for real-time interactions that are impossible with more state-heavy solutions.

Supports Parallel and Fan-Out Queries

Unmeshed allows for fan-out queries, enabling the platform to quickly access multiple backend systems, gather data, and transform it for API responses. This makes it easy to deliver comprehensive, real-time information to users. For instance, a fan-out query might retrieve user account data from one system, recent transaction data from another, and current offer information from yet another—all in one fast API call. Unmeshed manages this complexity without the latency typical of traditional orchestration platforms.

Seamless Data Transformation and Response Handling

API workflows often require data transformation before results are sent back to the client. Unmeshed handles these transformations on the fly, allowing API calls to return precise, user-ready data without additional processing delays.This capability is essential for delivering personalized or contextualized data directly to end-users in real time.

Unmeshed: Meeting Today’s Orchestration Demands

In today’s dynamic environment, businesses need an orchestration platform that can handle a range of use cases, from real-time API management to robust, long-running workflows. Unmeshed was built to fill this gap, offering a single platform capable of meeting both high-speed, low-latency requirements for APIs and the durability and reliability necessary for backend processes. By moving beyond the limitations of traditional orchestration platforms, Unmeshed empowers businesses to innovate faster, simplify integrations, and handle complex workflows—all while maintaining the performance needed for modern digital experiences.

Whether you’re managing high-frequency API calls or orchestrating critical backend processes, Unmeshed offers the flexibility and speed to keep your business agile and competitive. Curious to see Unmeshed in action? Chat with us and explore how our platform can empower your team to innovate and automate like never before.

Is an Orchestrator Really a Single Point of Failure?

The Unmeshed Team — Wed, 29 Jul 2026 05:30:02 +0000

Microservices architecture in a highly distributed system requires effective communication, that’s exactly where the orchestration and choreography come into play. Both are two fundamental approaches to managing workflows and data interactions between services. Each has its unique feature and use cases where it excels. Let’s break down the key differences, along with examples to illustrate where one might work better than the other.

Orchestration vs. Choreography: The Core Difference

Orchestration is a centralized approach, and the orchestration platform automatically coordinates the workflows by handling service-to-service communication, retrying failed tasks, and ensuring each service operates in the correct sequence.
Choreography, on the other hand, is a decentralized approach where each microservice independently interacts with other microservice based on predefined rules or events.

Key Differences

Aspect	Orchestration	Choreography
Control	Centralized control	Decentralized
Scalability	Highly scalable with multiple replicas of orchestrators	Complex to scale as independent interactions should be scaled to match requirements
Complexity	Work best in complex workflow, resilient	Harder initial setup effort and higher maintenance
Visibility	High – the orchestrator has visibility into the entire process	Requires a separate tracing tool and logging infrastructure to track
Usage	Decoupled microservices and APIs centrally coordinated by an Orchestrator. • Agentic AI Orchestration • API Orchestration • Workflows • Business Processes • Automation • Human Task Orchestration	Event-driven architecture built on loosely coupled systems tied together by an event broker. • Event Processing • Data Pipeline Flows

Orchestration

Choreography

Summary

Effectively both Orchestration and Choreography are similar. In the case of choreography, you are relying on a single message broker to reliably hold the messages for all the distributed services to consume and respond. In the case of Orchestrator, it acts as a smart message broker and calls the distributed services at the right time. The bonus point for Orchestrator is that it brings an incredible visibility into everything that is going on.

In simple event driven situations an Orchestrator may not be necessary such as storing events sent by a IoT device. However, in most situations where you need multiple steps to happen correctly an Orchestrator can add value by making it simpler to assemble these steps and giving you visibility into this.

A common argument is that an Orchestrator could be a single point of failure, however even in choreography the single point of failure exists in the form the message broker. So, choosing a reliable message broker or a reliable orchestrator can alleviate this concern. Platforms like Unmeshed can be used as an Orchestrator and it's designed to scale millions of requests per second reliably.

Your Sequential API Calls Are More Fragile Than You Think

The Unmeshed Team — Tue, 28 Jul 2026 05:44:16 +0000

Introduction

An API (Application Programming Interface) is a set of predefined rules and protocols that allows diﬀerent software applications to communicate with each other. APIs are bridging one application to request and retrieve data or services from another application, service, or system. It allows developers to use predefined functions or endpoints to integrate external features, retrieve information, or trigger operations without needing to know the underlying complexities of the system. APIs provide benefits that make them a cornerstone of modern software development. They enable seamless communication between microservices, which is particularly vital as microservices architectures have become a preferred approach for building scalable applications.

Challenges on calling APIs

The seemingly simple task of calling one API and then another can quickly become a challenging endeavor when factors like reliability, error handling, and system constraints come into play. Let's explore why this process is more complex than it appears and how platforms like Unmeshed simplify the problem.

Challenges in Sequential API Calls

Reliability and Error Handling

Consider the scenario where you first call an API to send a text message and then call another API to send an email. If the first call succeeds but the second fails due to a temporary issue (e.g., network latency or service downtime), your system needs robust error handling to ensure eventual success without duplicating eﬀorts. For instance, sending multiple text messages due to retries can lead to unnecessary costs and poor user experience. Handling such scenarios requires fine-grained control over retries and recovery strategies.

Cost Sensitivity

Some APIs are expensive to invoke, such as sending transactional messages or emails. You can't aﬀord to call these APIs multiple times unnecessarily. For example, if the email API fails after a text message is successfully sent, your system must handle this failure gracefully and retry intelligently without resending the text.

Rate Limiting

Many APIs impose strict rate limits, which means your system must carefully balance requests to avoid hitting those limits. For example, a bulk email service may restrict you to 100 calls per minute, while a payment processing API may limit you to 10 requests per second. To prevent breaches of these limits, you need a control mechanism to manage and queue API calls eﬀectively.

Monitoring and Visibility

Debugging and optimizing sequential API workflows can become a nightmare without proper observability. How do you determine which API is slowing down your process? What if a retry loop is failing silently?

How Platforms Like Unmeshed Help

A platform like Unmeshed addresses these challenges with a set of features tailored to API orchestration:

Chaining API Calls

Automatically coordinate workflows by chaining APIs together. For example, if you need to call a message API followed by an email notification API, Unmeshed ensures the sequence executes smoothly.

Rate Limiting

Built-in rate-limiting capabilities allow you to define how many requests are sent to each API. The system automatically queues additional calls, ensuring compliance with API provider constraints while avoiding bottlenecks.

Data Transformation

APIs often require specific data formats. Unmeshed can handle data transformation between calls, ensuring compatibility without additional development eﬀort.

Retries and Error Management

Intelligent retry logic ensures that temporary failures (e.g., a timeout while sending an email) are retried with appropriate backoﬀ strategies. You can also configure fallbacks, such as sending a push notification if the email fails repeatedly.

Visualizing Executions

Unmeshed provides a visual dashboard to monitor your API workflows in real-time. Track metrics like latency, success rates, and retry counts, enabling you to identify and resolve bottlenecks quickly.

Next Step…

By leveraging Unmeshed, you not only simplify your implementation but also make it robust, scalable, and cost-saving, ensuring seamless execution of even the most complex API workflows. API orchestration is a powerful tool for small and large-scale development teams managing complex microservices architectures. By centralizing and streamlining orchestration logic across services, businesses can enhance their system's performance and experience seamless scaling and evolution of their applications.

Does Perf Matter?

The Unmeshed Team — Mon, 27 Jul 2026 05:18:13 +0000

Introduction

I bet this is one of those questions that lingers in your mind, just like many others, when an orchestration platform is trying to convince you to choose their service. Yes, performance is a critical factor in orchestration platforms, particularly for high-scale use cases where transaction volumes and system demands are significant.

While traditional orchestration platforms prioritize features and reliability over raw performance, modern use cases often demand both high throughput and cost efficiency. That’s where Unmeshed steps in. Our orchestration platform is the tool you wish you’d had from the start—a reliable way to manage workflows, simplify microservices interactions, and keep everything running smoothly.

Why Performance Matters

Scalability Requirements

Traditional orchestration platforms, such as Netflix Conductor, were originally designed for slow-running, backend workflows where throughput was less critical. However, as businesses scale, the need for orchestrating millions or even billions of transactions daily requires platforms that can handle such loads efficiently without degrading performance.

Cost Implications

Performance directly impacts cost-effectiveness. An orchestration platform might function well at low transaction volumes, but if scaling up to handle larger workloads requires exponential cost increases, it becomes unsustainable. For example, spending $20,000 annually to process a few thousand transactions per second is fine but if cost increases to $200,000 for a larger volume it might be untenable.

Real-Time Use Cases

High-performance orchestration is critical for real-time applications, such as payment processing, IoT data pipelines, or AI-driven workflows, where latency and throughput are non-negotiable.

Unmeshed: A Cost-Effective Performance Solution

Unmeshed is a prime example of how performance and cost efficiency can go hand-in-hand. With a single instance capable of handling up to 10,000 transactions per second (TPS), Unmeshed enables nearly 1 billion transactions daily with ease. For even larger workloads—like 10 billion transactions—it’s as simple as scaling the cluster by adding more instances, all while maintaining efficiency without skyrocketing costs. Unlike traditional platforms that often struggle to balance high performance with affordability, Unmeshed delivers exceptional throughput at a fraction of the cost. This makes it an ideal solution for long-term, high-volume use cases where scalability and cost-effectiveness are key.

In brief, we conclude that the sweet spot in achieving high performance lies in cost efficiency and being capable of scaling workflows efficiently without overshooting their budgets.

High Performance + High Cost:

Unsustainable for most businesses in the long run, especially at scale.
Moderate Performance + Low Cost:

Suitable for simple, low-throughput workflows but inadequate for complex, large-scale operations.
High Performance + Low Cost (Optimal):

Ideal for scaling workflows efficiently while maintaining budgetary control—this is where platforms like Unmeshed excel.

Final Thought

When evaluating an orchestration platform, performance alone isn't enough; it must be considered alongside cost efficiency to determine true value. A platform offering high performance at a high cost is often unsustainable for businesses in the long run, particularly at scale. On the other hand, moderate performance at a low cost might work for simple, low-throughput workflows but falls short when handling complex, large-scale operations. This is precisely where platforms like Unmeshed shine, delivering the perfect balance of speed, scalability, and cost-effectiveness to support long-term growth and high-volume use cases.