DEV Community: Andrii B.

What a Store Project Really Costs: The Problems Drive It, Not the Platform

Andrii B. — Thu, 24 Sep 2026 22:27:00 +0000

A common first question from store owners is what a project costs on Shopify compared with Adobe Commerce. It is a reasonable question with a disappointing answer: the platform is rarely what decides the bill. We compared the licences in what Adobe Commerce, Shopify and BigCommerce actually cost, and even there the licence was usually the smallest number in the total.

What decides the bill is the set of problems the store already has, most of which sit outside the storefront. That is why we won't quote a figure on the first call, and why the quote we do write is split into phases, each with its assumptions written down.

Why a price list can't answer the question

Two stores on the same platform, with the same number of products, can need very different projects. One keeps its stock in Shopify and ships from one warehouse. The other has stock mastered in an ERP, a courier with its own API, a finance team that needs every invoice to match, and a marketplace feed with its own format. The storefront work is similar. Everything around it isn't.

So our honest answer to "what does it cost" is the shape rather than a number: an integration or a focused piece of work is usually measured in weeks, a platform build in months. What moves a project from one end of that range to the other is what the rest of this piece is about.

For a sense of scale: a first integration phase usually lands between 1 and 3 weeks.

The problems that actually move the number

Two systems that both think they own the truth. Most integration bugs are not code failures. They are two systems both believing they own the price, or the stock level, or the customer record. Until someone decides which system is the record for each field, every connector built on top inherits the argument. Deciding it costs a workshop. Not deciding it costs a campaign weekend of oversold products.

Stock that lives somewhere else. If inventory is mastered in an ERP or a warehouse system, the store only knows what the last sync told it. Whether that sync needs to be near real time or can run nightly is a business decision, and it is worth making per data type: stock usually needs to be fresh because being wrong means an oversell, while financial postings are often fine overnight. Making everything real time "to be safe" is one of the quietest ways to inflate a budget.

Product data nobody has cleaned. Catalogues accumulate attributes in the wrong places: sizes in tags, materials in titles, variants split into separate products. Every migration, search project or AI channel has to deal with it. It also costs sales directly: Baymard's usability research found that 10% of the largest e-commerce sites don't keep a consistently high level of detail in their product descriptions, and test users abandoned products when they couldn't find what they needed. Cleaning data is unglamorous work that no platform does for you.

Business rules that don't fit a cart. Rentals with availability windows, marketplaces with per-vendor payouts, configurators where the price depends on a dozen inputs. These bend a platform until the workarounds cost more than building the part that is genuinely yours. The test we use is simple: list the five things a platform would force you to work around. If they are cosmetic or only affect the admin, stay on the platform. If they touch how money is calculated, how inventory behaves over time or who is party to a transaction, it is time to look at custom.

Integrations someone else built. Fixing those is a good share of what we do. We start by instrumenting the connector to find where records actually go missing, which is frequently somewhere other than where the team suspects, and the fix is sometimes small. Sometimes the honest answer is that a rewrite is cheaper than another patch. Either way, you can't price it before you look.

One example from our own work: a client came to us for a redesign. Discovery showed that half their product attributes lived in tags and titles, and cleaning the catalogue took longer than the theme work, close to two months.

How we turn problems into a quote

Discovery first, when it isn't obvious. A short discovery maps the systems, the constraints and what is genuinely in the way, and ends with a written recommendation. Sometimes that recommendation is that you don't need a build at all, which is a cheaper answer than finding out six months in.

Phases, with the assumptions written down. We quote per phase so you can see what moves the number before you commit to the whole thing. If an assumption turns out to be wrong, it is visible which part of the price it affects.

Fixed price where the scope is precise. A migration, a connector or a defined feature set can be fixed-priced. Ongoing product work is better on a monthly team, because pretending an evolving roadmap can be fixed-priced usually ends in an argument about what was in scope.

Start with something small. A first phase that ships something real tells you more about working with us than any reference call, and it tells us more about your systems than any discovery document.

What makes the same project cheaper

A few decisions reliably take cost out before any code is written:

Pick one system of record per field and write it down.
Decide batch or real time per flow, not globally.
Build the risky part first. Whatever is most likely to be wrong, the pricing engine, the availability calendar, the payout maths, gets built and tested against real data early.
Look for the platform-shaped answer before the custom one. If Shopify, BigCommerce, Adobe Commerce or Medusa can carry the model with reasonable extension, that is the cheaper project.

What to bring to the first call

You don't need a specification. These five things are enough to turn a conversation into an estimate:

The list of systems around the store: ERP, warehouse, PIM, couriers, marketplaces, finance.
Which system is the truth for stock and price today, even if the answer is "it depends".
Three things that currently go wrong, in the words the operations team uses.
The rules that make your business unusual: how price is derived, how availability works, who gets paid what.
What a good first phase would change for you, in one sentence.

If you would rather work through your own list with us, talk to us.

Product data figures from Baymard Institute's research on product descriptions. Zelpex's approach as described on our custom e-commerce and integration pages and in our FAQ.

Originally published at zelpex.com.

You Don't Need Adobe Commerce Cloud to Survive Black Friday

Andrii B. — Thu, 24 Sep 2026 09:55:17 +0000

Everyone treats Adobe Commerce Cloud like it's the only thing standing between their store and a Black Friday meltdown. It's the platform that survives the spike, the managed fortress you can't possibly replicate, the reason the six-figure invoice is worth it. So let's pull the curtain back and look at what a Pro production environment actually is.

It's three virtual machines behind a load balancer, replicated across three AWS availability zones. That's it. That's the fortress. Adobe's own architecture docs describe the Pro production environment as having "three virtual machines (VMs) behind an Elastic Load Balancer," and each project "replicated on three separate AWS or Azure Availability Zones." Once you've seen that, the Black Friday question changes shape completely. It stops being "how do I buy the platform that survives" and becomes "can I build a three-node, multi-AZ cluster on AWS?" And you already know the answer to that one.

What Adobe Commerce Cloud Pro actually is

Strip the branding and Pro is a managed, dedicated cluster on AWS (Azure is an option, but AWS is the common case). Three nodes, and here's the part people get wrong: it's not a primary with two hot spares. It's active-active. Adobe runs a Galera cluster where "all three instances accept reads and writes," with an auto-increment setting of three so IDs stay unique across every node. They explicitly contrast this with "a traditional active-passive master or master-slave setup." All three nodes take traffic, all three take writes, and losing one AZ doesn't take the store down.

Each of those three nodes carries the full stack:

Fastly in front for CDN, WAF, and image optimization (more on that below).
NGINX with PHP-FPM as the web tier.
Galera / MariaDB as the active-active database, one instance per node.
Redis (Valkey on newer releases), one server per VM, "with only one active and the other two as replicas."
Elasticsearch or OpenSearch for catalog search, and which one depends on your version. Elasticsearch on older Commerce releases, OpenSearch from 2.4.4 onward. Never say just "Elasticsearch" without checking the version, because on a current store it's almost certainly OpenSearch.
GlusterFS as the shared file store, keeping media and static assets synced across the three nodes.

Now, the "six nodes" number you may have heard is real, but it is not the baseline. Adobe's scaled architecture splits the stack into a tiered layout: "a minimum of six nodes: three nodes for the core database and services and three nodes for the web server." That only kicks in on "the Pro 48 cluster or greater." So the default Pro store surviving your Black Friday is three nodes, and the six-node split is a bigger-plan upgrade, not the standard. If someone tells you Adobe Cloud is inherently a six-node monster, they're describing a tier most stores never buy.

The part that actually survives the spike

Here's the thing worth internalizing before you write a check: none of what makes this cluster survive Black Friday is proprietary Adobe magic. It's a handful of well-understood architecture decisions, and every one of them is a pattern you can name.

Full-page caching at the edge. Fastly is a Varnish-based service that caches "site pages, assets, CSS, and more" at global edge nodes. On Black Friday, the overwhelming majority of your traffic is people looking at the same category and product pages. If those are served from cache, they never touch PHP or the database at all. This is the single biggest reason the cluster holds: the origin only sees the long tail of uncacheable, personalized, add-to-cart requests. Fastly also runs the WAF, though note it's "available on Pro and Starter Production environments only," so your staging traffic isn't behind it.

An active-active database with no single writer. Because all three Galera nodes accept writes, there's no lone primary whose death stops checkout, and no failover dance while the replicas get promoted. Don't read that as three times the write throughput, though. Every write is still certified and applied on every node, so Galera buys you availability and spread-out connections, not linear write scaling. For a Black Friday store, availability is the part that matters.

A web tier you can throw hardware at. NGINX and PHP-FPM are stateless request handlers. The session and cart state live in Redis, the catalog in the database and search index. That statelessness is what makes horizontal scaling possible at all: nothing about node two knows or cares what node one just served.

Multi-AZ as the failure story. Three availability zones means a whole datacenter can have a bad day and your store stays up on the other two. This isn't a performance feature, it's a survival feature, and it's the one people most often skip when they roll their own and then regret at the worst possible moment.

Four patterns. Edge cache, active-active writes, stateless autoscaling web tier, multi-AZ redundancy. Hold onto those, because rebuilding Adobe Cloud is really just rebuilding those four things.

Rebuilding it on AWS

You don't have to guess at the mapping, because AWS published it. Their whitepaper on migrating Magento Open Source or Adobe Commerce to AWS lays out a reference architecture that mirrors the Adobe Cloud stack service-for-service. AWS has since stamped it "for historical reference only," and the software versions in it have aged, but the service mapping hasn't. The pieces line up like this.

The mappings, straight from AWS's reference:

CDN: Amazon CloudFront (or keep Fastly in front of AWS, plenty of stores do).
Full-page cache: Varnish on EC2 in an Auto Scaling group. AWS's own reference keeps Varnish rather than leaning entirely on the CDN, which mirrors Magento's built-in Varnish integration.
Load balancing: Application Load Balancer across multiple AZs.
Web / PHP tier: EC2 instances in an Auto Scaling group across multiple availability zones. ECS or EKS is a common modern variant, but the AWS whitepaper itself uses plain EC2 plus autoscaling, so don't feel you need containers to be legitimate here.
Database: Amazon RDS for MySQL or Aurora, and if you pick Multi-AZ, AWS deploys "a synchronously replicated secondary database" with "automated failover from the primary." That's not literally Galera active-active, and that's an honest difference worth sitting with: Aurora Multi-AZ gives you synchronous replication and automatic failover, not three simultaneously-writable nodes. For the vast majority of stores, failover-in-seconds is what you actually needed anyway.
Cache: Amazon ElastiCache with the Redis engine.
Search: Amazon OpenSearch Service.
Message queue: Amazon MQ, the managed AMQP broker that stands in for RabbitMQ.
Shared media: AWS's reference uses Amazon S3 via the remote-storage module. If you want the closer analogue to GlusterFS's POSIX shared mount, EFS does that, at a different cost profile. Both are legitimate; S3 is what AWS reached for.

The load-bearing piece, the database, is a few lines of Terraform. Multi-AZ with automatic failover, plus a subnet group that spans three zones so the standby always lands somewhere other than the primary:

# Plain RDS for MySQL. Aurora is a different resource shape
# (aws_rds_cluster + aws_rds_cluster_instance), same idea.
resource "aws_db_instance" "commerce" {
  engine                  = "mysql"
  instance_class          = "db.r6g.2xlarge"
  allocated_storage       = 500
  multi_az                = true          # synchronous standby in a second AZ, automatic failover
  backup_retention_period = 7
  storage_encrypted       = true
  # subnet group spanning three AZs so the standby lands in a different zone
  db_subnet_group_name    = aws_db_subnet_group.three_az.name
}

resource "aws_db_subnet_group" "three_az" {
  name       = "commerce-three-az"
  subnet_ids = [aws_subnet.az_a.id, aws_subnet.az_b.id, aws_subnet.az_c.id]
}

And the web tier is an Auto Scaling group that adds PHP-FPM instances when CPU climbs, which is exactly the behavior you want when the 9am doorbuster hits:

resource "aws_autoscaling_group" "web" {
  min_size            = 3                # one warm instance per AZ
  max_size            = 30              # room to absorb the spike
  vpc_zone_identifier = [aws_subnet.az_a.id, aws_subnet.az_b.id, aws_subnet.az_c.id]
  target_group_arns   = [aws_lb_target_group.web.arn]

  launch_template {
    id      = aws_launch_template.php_fpm.id   # NGINX + PHP-FPM baked into the AMI
    version = "$Latest"
  }

  # scale out on sustained CPU - the doorbuster signal
  # (a target-tracking policy at ~60% CPU is the boring, correct default)
}

None of this is exotic. It's the standard AWS reference architecture, and it produces the same four survival properties the Adobe cluster has.

What you actually give up (and what you gain)

So if the architecture is reproducible, what is Adobe's invoice buying? Be honest about this, because it's the whole decision.

You give up operations. Adobe patches the OS, manages the Galera cluster, runs the Fastly relationship, bundles New Relic, mirrors your production topology in a Staging environment, and answers the phone when something breaks at 2am. That last one is not nothing. When you self-host, the pager is yours. The person who wakes up when RDS fails over is on your team, not Adobe's. For a lot of merchants, "we don't want to be the ones holding the pager on Black Friday" is a completely rational reason to pay.

You also give up some conveniences that are genuinely bundled: Fastly at no additional cost, a Staging environment that mirrors Production, the managed WAF, the support SLA. Rebuild it yourself and each of those is a line item and a responsibility.

What you gain is control and economics. You pick your AWS region instead of taking whatever Adobe provisions. You get root on your own boxes. You're not gated behind a Pro 48 plan to split your tiers, you scale exactly the component that's hot. And past a certain size, the raw AWS bill for this architecture is a fraction of the Adobe Cloud license, because you're paying for compute instead of for compute-plus-platform-plus-support.

So do you need it?

Here's the verdict, and it's a fork, not a slogan. Surviving Black Friday is an architecture problem, and the architecture is a three-node, multi-AZ, edge-cached, autoscaling cluster that you can absolutely build on AWS. Adobe Commerce Cloud does not sell you a secret that makes traffic spikes survivable. It sells you the operational burden lifted off your team, on infrastructure that is, underneath the branding, a standard AWS deployment.

So the real question was never "can my store survive Black Friday without Adobe Cloud." It obviously can. The real question is "do I want to run this myself, or pay someone to run it for me." If you have a platform team that's comfortable with Terraform, RDS failover, and an on-call rotation, self-hosting gets you the same survival properties with more control and a smaller bill. If you don't, and you'd rather your engineers ship features than babysit a Galera cluster at midnight, then paying Adobe to hold the pager is a defensible call, as long as you're paying for the operations and not because you believed the infrastructure was something you couldn't build.

Just don't let anyone tell you it's a fortress you couldn't have built. It's three nodes behind a load balancer, across three zones. You've built bigger.

Originally published at andriiboyko.com.

UCP, Storefront MCP and Your Catalog: Getting a Shopify Store Agent-Ready

Andrii B. — Thu, 24 Sep 2026 09:47:49 +0000

In April 2026, developers on Shopify's community forum started reporting that their shopping assistants had stopped finding products. Calls to search_shop_catalog, the Storefront MCP tool for searching a store's products, began returning Tool not found. It had been replaced by search_catalog, on a different endpoint, with a new input schema.

That is a small incident and a useful one. The layer AI agents use to shop on Shopify is still moving, and getting a store agent-ready isn't a setting you flip. It means knowing which of three layers you depend on, and which parts of your own catalogue decide whether an agent can sell anything at all.

Three layers, one catalogue

Shopify Catalog is the syndication layer. Eligible products are made discoverable to AI channels, which Shopify currently lists as ChatGPT, Google AI Mode and Gemini, Microsoft Copilot and Meta, with their title, description, options, images, price and availability. Shopify says it keeps inventory and pricing updated continuously across those channels. For most merchants this is the whole integration: nothing to build, but nothing to tune either, except the data you feed it.

Storefront MCP is the per-store interface. A Shopify store exposes an MCP server that an agent can call directly, without authentication, using JSON-RPC 2.0 over HTTP POST. This is what a custom assistant, or any agent that talks to your store rather than to a marketplace, actually uses.

The Universal Commerce Protocol (UCP) is the contract underneath. Shopify and Google co-developed it as an open standard for how agents discover products, negotiate what a merchant supports and run checkout. Merchants and agents publish profiles at /.well-known/ucp, each side declares its capabilities, and the session runs on the intersection. Checkout, orders and catalogue are separate capabilities, each versioned on its own.

The practical point for a technical lead: the first layer is Shopify's job, the second and third are contracts you may be coding against, and contracts at this stage change.

What an agent actually calls

Storefront MCP is now split across two endpoints on your store's domain:

https://{shop}.myshopify.com/api/ucp/mcp carries the UCP catalogue tools: search_catalog, lookup_catalog (up to 10 ids per call) and get_product.
https://{shop}.myshopify.com/api/mcp carries the rest: search_shop_policies_and_faqs, get_cart and update_cart.

The UCP tools expect an agent profile in every request and wrap their arguments in a catalog object. This is the shape from Shopify's documentation:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "id": 1,
  "params": {
    "name": "search_catalog",
    "arguments": {
      "meta": {
        "ucp-agent": {
          "profile": "https://shopify.dev/ucp/agent-profiles/examples/2026-08-25/valid-with-capabilities.json"
        }
      },
      "catalog": {
        "query": "organic coffee beans",
        "context": { "address_country": "US", "intent": "Customer prefers fair trade products" }
      }
    }
  }
}

If you wrote an agent against the older flat search_shop_catalog call, the April change is exactly what broke it. The fix is small; the lesson is to treat the tool list as something you discover at runtime (tools/list is part of MCP), pin behaviour behind your own adapter, and alert on Tool not found rather than on empty results.

Checkout is a state machine, not a redirect

UCP models checkout as a session that moves through states, including incomplete, requires_escalation and ready_for_complete. When the merchant needs something only a person can provide, the session escalates and returns a continue_url; the buyer follows it and, in Shopify's words, "picks up exactly where the agent left off" in an embedded checkout.

That changes what you test. The question is not whether an agent can reach your checkout, but which of your checkout rules push a session into escalation: custom validation, required fields your storefront adds, logic that lives in a theme rather than in the platform. Every escalation is a hand-off from a conversation to a web page, and some buyers won't make it across. Walk your real checkout through the agent path and list what escalates before you promise anyone "buy inside ChatGPT".

The catalogue work that decides whether agents can sell

Most of the effort sits here, and none of it is new code.

Eligibility. Shopify Catalog only includes products with a title, at least one image and a price above zero, published to the online store, Hydrogen or a headless channel. Agentic storefronts also need an external product URL for each product, stored in the external URL standard metafield. A product that fails any of these is invisible to agents, however good it is.

Structure. Shopify's own guidance is to group genuine variants under one parent, so an agent understands one product with options rather than twelve near-duplicates, and to use the most specific category available: "men's insulated winter boots", not "footwear". It also asks for literal descriptions. Marketing copy that works on a landing page gives a language model very little to match against.

Data that lives in the wrong place. Plenty of mature stores keep real attributes in tag prefixes, metafields, metaobjects or split titles. Shopify Catalog Mapping exists for exactly this: it points the catalogue at where your data actually lives. If your size, material or compatibility data is in a tag like size:42, map it before assuming agents can see it.

B2B separation. Agentic storefronts are for direct-to-consumer sales. Shopify excludes B2B-only products it can identify through B2B catalogues, customer account requirements or password-protected storefronts, but a custom B2B implementation may need products hidden by hand, by setting them to Unlisted. A store that mixes trade and retail pricing through its own logic should check what agents are actually offered.

Stock you can promise. Shopify's line is that price and inventory "need to be accurate at the moment of the shopper's query". If stock is mastered in an ERP or WMS and synced to Shopify on a schedule, the agent sells from the last sync. On a busy day that is the difference between an order and a cancellation, and an agent-driven cancellation is a worse experience than a normal one, because the buyer never saw your store.

A readiness pass, in order

Run an eligibility report over the catalogue: no image, zero price, missing external URL, unpublished to the right channel. Fix these first; they are binary.
Map your data. List every attribute that lives in tags or metafields and set up Catalog Mapping for it.
Collapse false variants into single products with options, and tighten categories.
Decide what agents must not sell, especially trade-only items, and set them to Unlisted if Shopify can't detect them.
Measure your stock lag. How long between a change in the system that owns inventory and the same change in Shopify? If the answer is minutes, fix the sync before you invite agents in.
Walk checkout through the agent path and list every rule that escalates.
If you run your own agent, wrap the MCP calls behind an adapter, discover tools at runtime and alert on renamed or missing tools.

Shopify reports that AI-referred orders grew nearly 13x year over year. An agent buying on a shopper's behalf never sees your theme. What it sees is your catalogue data, so that is where the work goes.

If you would rather go through this against your own catalogue and integrations, talk to us.

Verified against Shopify's Storefront MCP documentation, the Shopify Engineering post on UCP, the Help Center pages on agentic storefronts and catalogue product discovery, Shopify's guide to agentic-ready product data, and the community thread on the tool rename, in September 2026.

Originally published at zelpex.com.

Magento 2.4.6 Lost Support in August: What Waiting Actually Costs

Andrii B. — Wed, 23 Sep 2026 18:19:09 +0000

If your store runs Magento 2.4.6, it stopped receiving security patches on 11 August 2026. The one exception is Adobe Commerce, the paid edition, which gets one more year. Magento Open Source, the free edition, does not.

So the decision in front of you is about exposure, not features: how long you are willing to run a checkout that nobody will fix when the next hole is found, and what it costs to stop.

Who is out of support, and until when

Adobe gives every 2.4 release three years of standard support, then stops shipping patches for it. For 2.4.6 and 2.4.7 it adds one extra year, but its lifecycle policy grants that year to "Adobe Commerce customers" only.

Version	Standard support ended / ends	Adobe Commerce only, extended to
2.4.6	11 August 2026	31 August 2027
2.4.7	31 May 2027	31 May 2028
2.4.8	31 May 2028	–
2.4.9	31 May 2029	–

There is a second clock under the first, and it catches Adobe Commerce customers too. Magento 2.4.6 runs on PHP 8.1 or 8.2. PHP 8.1 stopped receiving security fixes on 25 November 2025, and PHP 8.2 stops on 31 December 2026. So even a licence holder using the extra year will spend most of it on a language version that no longer gets security fixes of its own. The extension buys time to plan the upgrade. It is not a place to stay.

What waiting has cost other stores

The usual argument for waiting is that nothing has gone wrong yet. The last two years of Magento security history say otherwise.

In June 2024 Adobe patched CosmicSting (CVE-2024-34102), a flaw that let attackers read files on the server, including the store's secret encryption key. Sansec, which monitors Magento stores, reported that by that autumn 5% of all Adobe Commerce and Magento stores had a payment skimmer on their checkout page: 4,275 stores, attacked by seven competing groups. Some of them had installed the patch. Patching did not invalidate keys that had already been stolen, so stores that skipped rotating the key stayed open.

In September 2025 Adobe shipped an emergency fix for SessionReaper (CVE-2025-54236), a critical flaw that could lead to remote code execution. Six weeks later, when attacks began, Sansec found 62% of Magento stores still unpatched.

Two things follow for a store deciding what to do about 2.4.6. The gap between a fix and mass exploitation is measured in weeks, not years. And on an unsupported version there is no fix to install when the next one arrives: you are in the 62% by default, with no way out except the upgrade you postponed.

The compliance side

If you take card payments, PCI DSS requirement 6.3.3 expects critical security patches to be installed within 30 days of release. Version 4.0.1 of the standard narrowed that to critical vulnerabilities only, but kept the deadline.

A store on an unsupported version cannot meet that requirement the ordinary way, because no patch will be released. That doesn't make you non-compliant overnight, and it isn't legal advice. It does mean that at your next assessment you will need to explain which compensating controls you rely on instead, and that conversation gets harder every month the version stays in place.

What the upgrade actually involves

The upgrade itself is rarely the expensive part. What makes it expensive is everything around the Magento code.

The infrastructure moves first. Magento 2.4.8 runs on PHP 8.3 or 8.4, and 2.4.9 only on PHP 8.5 with OpenSearch 3, so the hosting stack has to change along with the application. Then come extensions and integrations: Adobe's own guidance notes that Marketplace extensions and third-party integrations may be affected, and each one has to be checked, updated or replaced. A store with a handful of well-maintained extensions and a stock theme is a very different project from one with years of custom modules and a hand-built ERP sync.

That is also why the cost of waiting compounds. Adobe says plainly that regular updates take less overall effort than infrequent ones. A store that moves every release does a small upgrade each time. A store that skips two or three does all of them at once, under pressure, usually after something has already gone wrong.

Our view on the target: go to the newest release your extensions support. If everything you rely on runs on 2.4.9, that buys support until May 2029. If a critical extension isn't ready, 2.4.8 is a sound stop until May 2028, and the next step from there is smaller.

The options, honestly

Upgrade on Magento. For most stores this is the answer. It keeps your catalogue, customers, order history and integrations where they are.

Move to Mage-OS. Mage-OS is a community-maintained distribution of Magento Open Source that ships its own releases and security patches, with the aim of patching faster. It is currently based on Magento 2.4.9, so switching is itself an upgrade, not a way to stay on 2.4.6. It is worth considering if you would rather not depend on Adobe's release schedule for the free edition.

Replatform. If the upgrade estimate comes back close to the cost of moving, it is fair to ask whether Magento is still the right platform. That is a bigger decision with its own hidden costs; we compared the platforms in what Adobe Commerce, Shopify and BigCommerce actually cost.

Do nothing. A web application firewall and closer monitoring reduce risk while you plan. They buy time. They don't replace patches, and they don't help with the PHP version underneath.

Before you get an estimate

Four questions decide how big this job is:

Which edition are you on? Adobe Commerce gives you until 31 August 2027. Open Source gave you until 11 August 2026.
Which PHP version does the server run? If it is 8.1, the language itself is already out of security support.
How many extensions and custom modules does the store use, and who maintains them? This list drives the estimate more than anything else.
What sits around the store? ERP, PIM, payment and shipping integrations each need testing against the new version.

If you would rather work through this against your own store's extension list and integrations, talk to us.

Support dates verified against Adobe's software lifecycle policy and system requirements, and PHP dates against php.net, in September 2026. Incident figures from Sansec's reports on CosmicSting and SessionReaper; PCI DSS changes from the PCI Security Standards Council.

Originally published at zelpex.com.

When a Manufacturer's CRM Should Be Built, Not Bought

Andrii B. — Wed, 23 Sep 2026 17:50:28 +0000

Most manufacturers who ask whether they should build their own CRM are asking about the wrong piece of software. The part their sales team uses every day is close to a commodity, and buying it is usually right. The part their dealers, distributors and service technicians touch is where the business is genuinely different, and it is also where the licence bill grows fastest.

So the useful question is narrower: which part of the CRM should you build, and which part would you be foolish to build?

Why manufacturing sales breaks generic CRM

A CRM is designed around a contact, a deal and a pipeline. Manufacturing sales rarely looks like that. The customer is a distributor with negotiated contract pricing. The order is a spare part identified by a code that was superseded two revisions ago. The delivery date depends on a production slot the ERP knows about and the CRM does not. And the person asking is often a technician on a plant floor, not a buyer in an office.

None of that data belongs to the CRM. Price, availability and lead time live in the ERP, and they have to stay there. Every CRM project for a manufacturer therefore turns into the same work: showing people outside the ERP an honest answer from inside it, without exposing how complicated it is to produce. That is true whether you buy the CRM or build it, and it is the part of the budget people tend to underestimate.

What buying actually costs

The vendors built for this are not cheap, and they price per person. Salesforce's industry product for manufacturers, Manufacturing Cloud, lists at $275 per user per month for its Sales or Service "Core" editions, $425 for the Advanced edition, and $650 to $700 for the "Max" editions that bundle its AI agents, all on annual contracts. HubSpot's Sales Hub is the lighter alternative at $90 per seat per month on Professional (billed annually) and $150 on Enterprise, plus a mandatory one-off onboarding fee of $1,500 or $3,500.

Seats for your own staff are only half the bill. The other half is everyone outside the company who needs to log in.

Salesforce prices its partner portal, Partner Relationship Management, at $25 per member per month, with a more capable tier at $50 and login-based pricing available for users who rarely sign in. Run the list prices for a hypothetical mid-size manufacturer: 15 internal users on Manufacturing Cloud Sales Core and 300 dealer accounts on the partner portal.

Line	Calculation	Per year, list price
Internal users	15 × $275 × 12	$49,500
Dealer portal members	300 × $25 × 12	$90,000
Total licences		$139,500

The dealers cost almost twice as much as the sales team, before a single integration is built. List prices get discounted and login-based licences cut the portal line for dealers who sign in rarely, so treat the table as the shape of the bill rather than a quote. The shape is the point: in manufacturing, the external audience is usually larger than the internal one, and per-member pricing scales with it every year.

The quoting trap

Quoting is usually where a packaged CRM starts to fit badly. Prices come from rules, not a table: the customer's contract, the volume, the configuration, which options are compatible with which, and what the ERP says a variant actually costs to make.

The standard answer used to be Salesforce CPQ, and it is no longer sold to new customers. Existing customers keep it, with support and renewals but no new features, while new buyers are pointed at its successor, Revenue Cloud Advanced. Salesforce is careful to call this end of sale, not end of life. For a manufacturer choosing today, though, it means the configure-price-quote layer most comparison articles describe is not the one you would be buying, and a quoting project is a separate licence and a separate implementation on top of the CRM.

This is the first place building starts to make sense. If your pricing logic is yours alone, encoding it in a quoting tool you own is often cheaper and clearer than bending a generic rules engine around it.

Where building earns its place

We would split the system in three and treat each part differently.

The internal CRM: buy it. Accounts, pipeline, activity history, service cases, reporting. This is well-solved software. Building it means rebuilding permissions, audit trails, email sync and mobile access that a vendor already maintains, and your team would be maintaining them for ever.

The ERP: leave it alone. It is the system of record for price, stock and lead time. Neither the CRM nor anything you build should hold a second copy of those numbers that can drift.

The dealer portal and quoting rules: build them when they are where you compete. This is the software your customers actually use. It carries your contract pricing, your supersession chains for spare parts, your serial-number history for service, and your availability promises. A custom portal is priced once to build and then maintained, not charged per dealer per month, and it can read the ERP directly instead of through a CRM in the middle.

The split is not free. A custom portal needs an owner, a hosting bill, security updates and someone who understands it when the person who built it has moved on. If you have no one to own software, the per-member licence is the price of not needing them, and it can be worth paying.

The test

Before deciding, answer four questions honestly.

How many people outside the company need to log in? If it is a handful, a vendor portal is fine. If it is hundreds of dealers or technicians, price the per-member line over five years before anything else.
Is your pricing a table or a set of rules? A price list fits any CRM. Contract pricing, configuration rules and ERP-derived costs are where packaged quoting gets expensive and awkward.
Where does the true answer on availability live? If it is the ERP, whatever customers see has to read from it, and that integration is the real project either way.
Who will own the software in three years? Building only works if the answer is a named person or a partner, not "IT".

If the answers are "few", "a table", "the ERP" and "nobody", buy the whole thing and keep the configuration shallow. If they are "hundreds", "rules", "the ERP" and "we can", buy the CRM, build the portal, and let the ERP stay the source of truth.

If you would rather work this through against your own dealer network and pricing rules, talk to us.

Prices verified against Salesforce Manufacturing Cloud, Salesforce Partner Relationship Management and HubSpot Sales Hub pricing pages, and Salesforce's CPQ end-of-sale page, in September 2026. All figures are list prices in US dollars.

Originally published at zelpex.com.

MedusaJS Dropped the Foreign Keys Between Its Modules: The defineLink Gamble

Andrii B. — Tue, 22 Sep 2026 18:57:18 +0000

MedusaJS 2.0 did something that would get a junior engineer's pull request rejected on sight: it deleted the foreign keys between its own tables. On purpose. Not by accident, not as tech debt, but as the load-bearing decision of the whole architecture. The release notes say it in one flat sentence, and it's worth reading twice: "We've also eliminated all database-level dependencies, removing foreign keys between data models in different modules."

If you grew up on Rails, Django, or a decade of Magento's EAV tables, that line should make you flinch. Foreign keys are how the database protects you from yourself. They stop orphaned rows, they cascade deletes, they turn "these two things are related" into a rule the storage engine enforces whether your application code remembers to or not. MedusaJS looked at all of that and decided the cost was too high. This is the defineLink gamble, and once you understand what it buys and what it takes away, you'll either love it or quietly plan your reads around it.

What module isolation actually buys

Start with the why, because the no-foreign-keys thing sounds reckless until you see the constraint it's serving.

MedusaJS 2.0 ships its commerce logic as separate modules, twenty-plus of them, from Product and Pricing to Cart, Order, Inventory, and Fulfillment. Each one is a self-contained package: its own data models, its own service, its own migrations. The rule that makes them modules rather than just folders is isolation. The docs are blunt about it:

A module is unaware of any resources other than its own, such as services or data models.

So the Product module can't reach into the Pricing module's service, and the Pricing module's tables can't hold a relationship to the Product module's tables. There's no product_id foreign key sitting on a price row pointing back across the boundary. The release blog frames it as a rewrite from the ground up: "all business domains (services and data models) have been rewritten from scratch to eliminate interdependencies between them."

The payoff is portability. Because a module knows nothing about its neighbors, you can swap MedusaJS's built-in Pricing module for your own, run a module against a different datastore, or lift one out and use it somewhere else. A foreign key is the enemy of that goal. The moment the Pricing table references the Product table at the database level, the two are welded together forever, and you can never move one without the other. MedusaJS's bet is that in a commerce platform people actually customize, replaceable parts are worth more than referential integrity across those parts.

One myth to kill early: isolation does not mean every module gets its own database. By default they all share one Postgres. Isolation is enforced in the code and the schema, not by physically scattering your data. You can point a module at a separate datastore if you want, but you don't have to, and most people don't.

The link table, not the foreign key

So if a price can't point at a product with a foreign key, how do you say "this price belongs to this product"? You define a link.

A link lives in its own file under src/links, and you declare it with defineLink, wiring together the linkable handles that each module exposes for its data models:

// src/links/product-post.ts
import BlogModule from "../modules/blog"
import ProductModule from "@medusajs/medusa/product"
import { defineLink } from "@medusajs/framework/utils"

export default defineLink(
  ProductModule.linkable.product,
  BlogModule.linkable.post
)

That's the whole declaration for a link between a product and a blog post. Every module hangs a linkable property off its service holding these configs for its models, so you never touch the other module's internals, you just reference the handle it published.

Now here's the part that matters. When you sync this link, MedusaJS doesn't add a column to the product table or the post table. It creates a brand new table that sits between them:

npx medusa db:sync-links

That command (or db:migrate, which runs migrations and syncs links together) creates a link table named after both sides, something like product_product_blog_post. It has two columns: the product's id and the post's id. And the crucial detail, straight from the docs, is what those columns are not: they "store only the IDs of the linked records and do not hold a foreign key constraint."

Look at what just happened. The relationship exists, but it lives in a third table, and the database has no opinion about whether those IDs point at anything real. Delete a product and its row in the link table just dangles, pointing at a ghost. There's no ON DELETE CASCADE to clean it up, because there's no foreign key to hang the cascade on. That responsibility moved out of the database and into MedusaJS's application layer, where the framework manages links as records commit and delete. Whether you trust that trade is the entire question of the article.

Reading across the gap with Query

Fine, the relationship is in a link table. How do you actually read a product and its linked blog post in one go, without hand-writing joins across three tables? You use Query.

Query is MedusaJS's cross-module read tool. You resolve it from the container and call graph, describing what you want in a shape that looks a lot like GraphQL:

import { ContainerRegistrationKeys } from "@medusajs/framework/utils"

const query = req.scope.resolve(ContainerRegistrationKeys.QUERY)

const { data: posts } = await query.graph({
  entity: "post",
  fields: ["id", "title", "product.*"],
  filters: { id: "post_123" },
})

The magic is in "product.*". You ask for the post's own fields, then you reach across the link and pull the whole linked product too, all in one call. If the link is a one-to-many, you use the plural form, "products.*", and get an array back. Query knows about every module's models and every link between them, so it stitches the result together for you.

But read that word carefully: stitches. Query does not run a SQL join across the module tables, because it can't, there are no foreign keys to join on. Instead it builds an internal graph of your modules and their links, fetches from each module separately, and aggregates the pieces into the final result. The docs describe exactly this: "Medusa aggregates the data coming from different modules to create the end result."

For the common case, this is genuinely nice. Your module boundaries stay clean, you never write cross-module SQL by hand, and adding a new link is one defineLink file plus a sync. The gamble is paying off. And then you hit the wall.

The join you can't write

Here's the scenario that finds the edge. You want products in a specific sales channel, sorted by price, cheapest first. Product lives in the Product module. The sales-channel association is a link. Price lives in the Pricing module, another link. In a foreign-key world this is a two-join query with an ORDER BY, the kind of thing you'd write half-asleep.

In MedusaJS's aggregate-don't-join world, you can't. Because Query pulls from each module separately and merges afterward, it has no single result set to filter or sort by a linked module's field. The docs name the limitation directly: "This approach limits your ability to filter data by linked modules." Filtering by the post's own id is fine. Filtering products by a linked sales channel's id, or sorting them by a linked price, is not something plain query.graph can do, because at the moment it would need to filter, the linked data hasn't been joined in, it's still sitting in another module waiting to be aggregated.

This is the "what breaks the first time you need a real join" moment, and it's not a bug. It's the direct, unavoidable cost of deleting the foreign keys. You removed the mechanism that makes cross-entity filtering cheap, so cross-entity filtering got expensive. Nobody who chooses this architecture gets to be surprised by it. You either design your reads so the filter and sort always live inside a single module, or you reach for the escape hatch.

The escape hatch: the Index module

The escape hatch is the Index module, and it's MedusaJS's honest answer to the problem its own isolation created.

The idea is a central, read-optimized index. On startup and as data changes, MedusaJS ingests the modules' data into one relational store that does know how everything connects. Then you query that store, and because it's a single joined-up representation, you finally can filter and sort across module boundaries. The API is deliberately identical to Query, so switching is nearly free, you swap graph for index:

const { data: products } = await query.index({
  entity: "product",
  fields: ["*", "sales_channels.*"],
  filters: {
    sales_channels: { id: "sc_123" },
  },
})

That filters.sales_channels.id is the thing plain query.graph couldn't do: filtering products by a linked module's field. The docs put the division of labor plainly: "The Index Module adds a new index method to Query and it has the same API as the graph method," and it exists "to filter linked modules."

Now the catch, because there's always a catch. The Index module is experimental. The docs say so in as many words: "The Index Module is experimental and still in development, so it is subject to change." It's gated behind a feature flag and, as the team wrote in September 2025, it "is not used by default in the core APIs and workflows." It has been maturing steadily, more entities became ingestible in v2.10.2, caching arrived in v2.11.0, admin routes to inspect and resync the index landed in v2.11.2 at the end of October 2025, but it is not yet the default read path, and you shouldn't present it to yourself as one.

So the real state of the gamble is this: MedusaJS gave you a clean, isolated, foreign-key-free architecture today, and the tool that makes cross-module querying feel normal again is still growing up. If your product needs heavy cross-module filtering right now, you're either enabling an experimental module or shaping your data model so you don't need it. That's the tax, stated honestly.

Managing links at runtime

One more piece, because defining a link type is not the same as saying "this specific product is linked to this specific post." For that you use the Link service at runtime:

import { ContainerRegistrationKeys, Modules } from "@medusajs/framework/utils"

const link = req.scope.resolve(ContainerRegistrationKeys.LINK)

await link.create({
  [Modules.PRODUCT]: { product_id: "prod_123" },
  blog: { post_id: "post_123" },
})

link.create writes the row into that link table, and link.dismiss removes it, same shape. This is the application-layer bookkeeping that stands in for what a foreign key and a cascade used to do automatically. You create the association, you're responsible for tearing it down.

Warning
If you're reading an older tutorial that resolves remoteLink and calls it the current API, stop. As of MedusaJS v2.2.0, Remote Link was deprecated in favor of Link. Same usage, you just resolve LINK from the container instead. The one place the old name lingers is workflow steps, which still ship as createRemoteLinkStep, dismissRemoteLinkStep, and friends, so don't be surprised to see both spellings in the same codebase.

That split, a renamed service but legacy step names, is a small tell about how fast this part of MedusaJS is still moving. Which brings us back to whether the whole bet was worth making.

Is the gamble worth it?

Here's my read, coming from years of both Magento's foreign-key-everything schema and the microservices tax on the other extreme.

What MedusaJS built is a modular monolith with unusually honest boundaries. In a typical monolith, "modules" are a naming convention that a single JOIN quietly violates the first time someone's in a hurry. MedusaJS made that violation impossible at the database level. You physically cannot couple two modules through the schema, which means the boundaries you drew on the whiteboard are the boundaries you actually have in production a year later. Anyone who's watched a "modular" codebase rot into a big ball of cross-table joins knows how rare and valuable that is. You get the clean domain separation you chased with microservices, without paying for a network hop and a separate deploy per module.

The price is real and you should say it out loud: you gave up the database's referential integrity and its cheap cross-entity queries. Orphaned link rows are now your problem, not Postgres's. Cross-module filtering and sorting, the bread and butter of any admin grid or storefront facet, is either an experimental module or a data-modeling constraint you design around. That's not a small tax on a commerce platform, where "show me products in this channel sorted by margin" is a Tuesday.

So the honest verdict: the defineLink gamble is the right call when you're going to customize and replace modules, when clean boundaries matter more to you than referential integrity, and when your heavy filtering happens to live inside single modules. It's the wrong call if your product is one giant cross-module reporting surface and you need those joins today, because the tool that makes them painless is still wearing an experimental flag. MedusaJS bet that portability beats foreign keys for the kind of teams that outgrow Shopify and would otherwise fork Magento. For a lot of those teams, it's the right bet. Just go in knowing which half of the trade you're standing on.
Originally published at andriiboyko.com.

If you found this helpful, follow me here and on LinkedIn

AWS Step Functions vs Camunda for Sagas: Two Orchestrators, Different Blast Radii

Andrii B. — Sun, 20 Sep 2026 10:38:46 +0000

Here's a trap I've watched smart teams walk into. They pick a saga orchestrator by comparing the two engines feature-for-feature, decide they both "do sagas," flip a coin weighted by whatever's already in their cloud bill, and move on. Then a year later one team is tuning Zeebe partitions at 2am and the other is staring at a Step Functions bill that grew faster than their traffic, both wondering how the "same pattern" turned into such different jobs.

They do run the same pattern. A saga is a sequence of local transactions where, if step four fails, you run compensating actions to undo steps one through three, because you don't have a distributed transaction to roll back for you. Both AWS Step Functions and Camunda 8 are orchestration-style saga coordinators: a central brain that knows the steps, drives them in order, and triggers the rollback when something breaks. That part is genuinely the same.

What's not the same is what you're on the hook for. We run Camunda 8 in production for credentialing and scheduling workflows, so I've lived one of these; the other I've read the docs on and priced out for real proposals. The honest comparison isn't "which has more features." It's "which failure is yours to own." Let me lay both out.

The saga both of them run

Orchestration sagas need a coordinator because someone has to remember where the process is. Choreography (services reacting to each other's events with no central brain) works until you need to answer "why is order 8842 stuck," and then nobody can, because the state lives smeared across six services' logs. An orchestrator centralizes that: one place holds the process state, drives the next step, and owns the compensation logic.

So the shape is identical on both. Take a classic order saga: reserve inventory, charge the card, ship. If the charge fails, release the inventory. If shipping fails, refund the charge and release the inventory. Three forward steps, a compensation for each, run in reverse. The pattern is old and boring, which is the point. The interesting part is what each engine makes you do to express it, and what each one does when the wheels come off.

Step Functions: the orchestrator AWS operates for you

Step Functions is a managed state machine. You describe your saga in Amazon States Language, which is JSON, and AWS runs the thing. There are no brokers to operate, no cluster to size, no exporter to babysit. For a lot of teams that single sentence is the whole pitch, and it's a good one.

You get retries and error routing as declarative config. Here's the reserve-then-charge slice, with a retry on the flaky step and a Catch that routes a failed charge to the compensating action:

{
  "StartAt": "ReserveInventory",
  "States": {
    "ReserveInventory": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": { "FunctionName": "reserveInventory" },
      "Retry": [
        { "ErrorEquals": ["States.TaskFailed"], "MaxAttempts": 3, "IntervalSeconds": 1, "BackoffRate": 2.0 }
      ],
      "Next": "ChargePayment"
    },
    "ChargePayment": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": { "FunctionName": "chargePayment" },
      "Catch": [
        { "ErrorEquals": ["States.ALL"], "Next": "ReleaseInventory" }
      ],
      "Next": "Ship"
    },
    "ReleaseInventory": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": { "FunctionName": "releaseInventory" },
      "Next": "SagaFailed"
    },
    "SagaFailed": { "Type": "Fail", "Error": "SagaFailed" }
  }
}

Look at what compensation actually is here: it's you, by hand, pointing each step's Catch at the right cleanup state and remembering to undo everything that already succeeded. There's no "compensate the whole saga" primitive. If Ship fails, its Catch has to route to a state that refunds the payment AND then to a state that releases the inventory, in the right order. Miss one and you've got a half-rolled-back order and no error to tell you. The state machine is honest and explicit, which is a nice way of saying verbose and entirely your responsibility.

For long-running sagas you use Standard Workflows, and this is where the surprise lives. Standard Workflows bill per state transition. Every step your machine takes is a transition: a task, a wait, a choice. The first 4,000 a month are free, then it's $0.000025 each. Cheap, until you read the next sentence: every retry attempt is its own billed state transition. So the exact moment your dependencies are flaky and your saga is retrying and compensating, which is the moment you most need it to work, is also the moment it's transitioning the most and billing the most.

Do the math on a bad month. Say the order saga is six states on the happy path. Add a payment step that burns its three retries and then compensates two prior steps: call it eleven transitions for that execution instead of six. Now imagine a million sagas in a month running hot like that:

1,000,000 sagas x ~11 transitions = ~11,000,000 state transitions
minus 4,000 free
x $0.000025
= ~$275 / month, in Step Functions transitions alone
(Lambda invocations, and everything the tasks actually do, billed separately)

That number is small until it isn't. The point isn't the dollar figure, it's the shape of the curve: your orchestration cost scales with steps and with failures, not with business value. A retry storm is a billing event. For high-volume, short-lived sagas AWS pushes you to Express Workflows, which bill on requests plus duration plus memory instead, but Express caps how long a saga can run and changes the durability guarantees, so it's a different tool, not a cheaper Standard.

Human steps and long waits work through the callback pattern: a task pauses with a token and resumes when something calls back with that token. It's a clean primitive. It is also, again, plumbing you assemble. There's no built-in inbox, no task list, no assignment or escalation. If your saga has a "a human approves this" step, Step Functions gives you the pause and the resume and leaves the actual human workflow to you.

Camunda 8: the orchestrator you operate

Camunda flips almost every one of those tradeoffs. You model the saga in BPMN, and compensation is a first-class construct: you attach a compensation boundary event to each activity, define its handler (the undo), and when something throws, one compensation throw event fires all the relevant handlers, in reverse, automatically. You don't hand-route rollbacks. You declare "charging the card is compensated by refunding it" once, on the task, and the engine does the reverse walk. Camunda's own framing is that Zeebe acts as the saga coordinator that solves the transaction without two-phase commit, and the compensation modeling is the part that makes that pleasant instead of a pile of Catch states.

The workers are your code. A Zeebe worker subscribes to a task type and does the real work; throwing a BPMN error is what triggers the compensation path:

import { ZBClient } from "zeebe-node";

const zbc = new ZBClient();

zbc.createWorker({
  taskType: "charge-payment",
  taskHandler: async (job) => {
    try {
      await payments.charge(job.variables.orderId, job.variables.amount);
      return job.complete();
    } catch (err) {
      // A BPMN error, not a crash: the modeled compensation boundary
      // events upstream fire and unwind the saga for us.
      return job.error("PAYMENT_FAILED", "card declined");
    }
  },
});

Two things Step Functions makes hard, Camunda makes boring. First, human tasks are native: user tasks are part of the model, and since 8.5 you drive them through the Zeebe REST API, with a task list, assignment, and forms as real product surface rather than something you glue on. For our credentialing flows, where a human genuinely has to review and approve, that's not a nice-to-have, it's the reason the engine earns its keep.

Second, and this is the one people underestimate until it bites: in-flight process versioning. When you fix a bug in a saga that has thousands of instances mid-flight, deploying version two doesn't disturb the running ones; they finish on the version they started on. When you actually need to move them, you migrate in-flight instances, through Operate or the Zeebe API, and you can canary a new version against real traffic. A saga that spans days or weeks will outlive several deploys of its own definition. Having a real answer to "we changed the process while ten thousand of them were running" is the difference between a workflow engine and a fancy job queue.

The bill for all this is that you operate it. Even on Camunda's SaaS you're closer to the machine; self-managed, you're running Zeebe brokers, choosing a partition count, and feeding an exporter into Elasticsearch so Operate has something to show. Zeebe is a distributed, log-based engine, every state change is an append to a replicated log, which is exactly why it recovers cleanly and exactly why it's a real distributed system with your name on the pager. Nobody at AWS gets paged when your exporter falls behind.

Where the blast radii actually differ

Both engines can lose you a saga. What differs is which failure domain is yours.

With Step Functions, the engine's blast radius is AWS's problem. If a broker equivalent falls over, that's their incident, their multi-AZ replication, their 3am. Your blast radius moved somewhere else: into cost, which grows with every retry, and into lock-in, because Amazon States Language and the deep .sync and callback integrations don't travel. The day you want to run the same saga off AWS, you're not porting a config, you're rewriting the orchestrator. That's a real blast radius, it's just a slow one that shows up in a migration quarter instead of a pager.

With Camunda, the engine's blast radius is yours. A misconfigured partition count, an exporter that can't keep up, a botched broker upgrade, those are your incident. In exchange, you own the model. The saga is BPMN you can read, version, and migrate; the compensation is declared, not wired; the engine runs wherever you put it, on any cloud or none. Your blast radius is operational and immediate, but it's also fully in your hands, and it doesn't have a per-transition meter running.

Neither of these is the "safe" choice. They're different bets on which kind of failure you'd rather own: someone else's engine with your cost and lock-in exposure, or your own engine with your operational exposure.

The four questions that actually decide it

Skip the feature matrix. Four questions settle it in practice.

How gnarly is your compensation? If your rollback is "undo the last thing, maybe two," Step Functions' hand-wired Catch states are fine and the managed simplicity wins. If your saga has real compensation depth, conditional undo, partial rollbacks, compensation that itself can fail, Camunda's first-class compensation modeling stops being a nicety and starts being the thing that keeps the logic legible.

Are there humans in the saga? A step where a person reviews, approves, or fills in a form tilts hard toward Camunda. Step Functions can pause for a callback, but you're building the entire human side. Camunda ships it.

How long do instances live, and will the definition change under them? A saga that completes in seconds rarely outlives its own code. One that runs for days or weeks will, and in-flight versioning goes from "feature I skimmed" to "the reason we didn't have an outage on deploy." That's Camunda's home turf.

Who operates it, and what happens to the bill at scale? If you have no appetite to run a distributed engine and you're already all-in on AWS, Step Functions' managed model is a genuine gift, right up until the transition bill on a high-retry, high-volume workload makes someone ask why orchestration costs more than the work it orchestrates. If you have the operational muscle and you care about portability or predictable cost, running Camunda is a real option rather than a burden.

Here's my actual position, from the side I've lived: for the workflows we run, credentialing and scheduling, with human approvals, multi-day instances, and compensation that has to be right, Camunda was never a close call, and the operational tax has been worth every cent of not owning the model. But I've also priced Step Functions for a stateless, short-lived, no-humans, all-on-AWS saga and recommended it without flinching, because there the managed simplicity is the whole point and the transition bill stays small. The mistake isn't picking either one. The mistake is picking it because it "does sagas," and finding out a year later which blast radius you actually signed up for.

Originally published at andriiboyko.com.
If you found this helpful, follow me here and on LinkedIn

Nomad vs Kubernetes: When You Don't Need the Cluster

Andrii B. — Thu, 03 Sep 2026 11:47:34 +0000

Somewhere along the way, "we need to run some containers" quietly became "so we need Kubernetes," and the second half stopped getting questioned. You stand up a cluster, or pay for a managed one, and now you own a distributed control plane: etcd, an API server, a scheduler, a controller manager, plus a kubelet and kube-proxy on every node, and that's before the CNI plugin, the ingress controller, and the operators. For a fleet at Spotify scale, that machine earns its keep. For a team running twenty services, it's a lot of orchestrator to babysit for a job that was never that hard.

There's a quieter answer that's been in production at Cloudflare, Roblox, Trivago and CircleCI for years: HashiCorp Nomad. It's a single binary. The same executable is your server and your client; it stores its own state with built-in Raft and needs no etcd, no separate datastore, nothing external to coordinate. And to head off the obvious "toy" assumption: Nomad scheduled two million containers across 6,000 hosts in ten AWS regions in 22 minutes in HashiCorp's C2M benchmark, roughly 1,500 containers a second. Small to run is not the same as small in what it can do.

So the honest question isn't "Nomad or Kubernetes." It's "do you actually need the cluster, or did you reach for it out of reflex?" And in 2026 the answer turns on two axes most comparisons skip: what your workloads actually are, and who you're willing to bet your platform on.

What you're actually signing up for with Kubernetes

Kubernetes is not one thing you install. Its control plane is etcd (the distributed key-value store that holds all cluster state), the kube-apiserver, the kube-scheduler, and the kube-controller-manager; every worker node then runs a kubelet and kube-proxy. On top of that base you almost always add a CNI network plugin, an ingress controller, a certificate manager, a metrics stack, and a pile of operators, because the bare cluster doesn't do much until you assemble the ecosystem around it.

None of that is a criticism, exactly. It's the price of the most powerful, most extensible orchestrator ever built, and if you need that power the price is fair. But be honest about what it is: a distributed system with its own failure modes, its own upgrade dance every few months, and enough surface area that "Kubernetes engineer" is a full job title. Managed control planes (EKS, GKE, AKS) rent you the hard parts, but you still own the nodes, the add-ons, the YAML, and the upgrades. The complexity didn't leave; someone else runs a third of it.

The tell that you might be over-buying is simple: if you can't name a concrete thing your workloads need that requires this machine, you're paying for a distributed control plane to run what a much smaller tool would schedule fine.

What Nomad is, and the part people miss

Nomad's architecture is almost aggressively boring, and that's the pitch. One binary runs in one of two modes, server or client. Servers form a small Raft cluster (usually three or five) and hold state themselves; clients run the actual work. There is no etcd, no separate API tier, no per-node proxy to operate. You run the same binary everywhere and configure what it is. The operational surface is a rounding error next to a Kubernetes control plane.

But the differentiator that actually matters isn't "simpler Kubernetes." It's that Nomad is a workload orchestrator, not a container orchestrator. Kubernetes schedules pods, and a pod is containers. Nomad schedules through pluggable task drivers: docker for containers, but also exec for a raw Linux binary, java for a JAR, qemu for a full virtual machine. So the same scheduler that runs your new Go services also runs the legacy Java app nobody wants to containerize, a Windows service, and a batch process that's just an executable, side by side, on the same fleet. That's not a thing Kubernetes does gracefully, and for a shop with a mixed or legacy estate it's the whole ballgame.

Here's the same "run three copies of a web service" job, and the difference in machinery is the point. Nomad:

job "web" {
  group "app" {
    count = 3
    task "server" {
      driver = "docker"
      config { image = "myapp:1.4.0" }
      resources { cpu = 500, memory = 256 }
    }
  }
}

Kubernetes wants a Deployment and, to make it reachable, a Service:

apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
  replicas: 3
  selector: { matchLabels: { app: web } }
  template:
    metadata: { labels: { app: web } }
    spec:
      containers:
        - name: server
          image: myapp:1.4.0
          resources: { requests: { cpu: 500m, memory: 256Mi } }
---
apiVersion: v1
kind: Service
metadata: { name: web }
spec:
  selector: { app: web }
  ports: [{ port: 80, targetPort: 8080 }]

Neither is hard. But multiply that difference across every service, every environment, and every engineer who has to hold it in their head, and "a bit less machine per thing" compounds into a materially smaller platform to run.

The assemble-it-yourself tradeoff

Nomad's small size comes from doing one job: scheduling and resource management. It deliberately does not bundle service discovery, secrets, or a service mesh. Instead it leans on the rest of the HashiCorp stack: Consul for service discovery and mesh (a Nomad task registers itself in Consul automatically when it starts), and Vault for secrets. That's a genuine tradeoff with two honest sides.

The upside: each piece is separable and you run only what you need. A small service that just needs to be scheduled doesn't drag a mesh and a policy engine along for the ride. The downside: "the platform" is now a few HashiCorp tools you wire together yourself, and if you want the equivalent of what a mature Kubernetes install gives you out of the ecosystem, you're the one assembling and operating Consul and Vault next to Nomad. For a small platform team that's often a feature, fewer moving parts, each understandable. For a team that wanted batteries included, it can feel like more decisions than they signed up for.

The ecosystem, and the elephant in the room

Here is where the comparison stops being about architecture, because this is the part that actually decides it in 2026.

Kubernetes is a CNCF project. It's vendor-neutral, every cloud sells a managed control plane, and its ecosystem is the largest in infrastructure: an operator or a Helm chart for nearly everything, a service mesh menu, and, not trivially, a hiring pool where "we run Kubernetes" is a sentence every candidate understands. When you pick Kubernetes you are buying that gravity as much as the scheduler.

Nomad's ecosystem is a fraction of that, and, more importantly, its ownership story changed. In August 2023 HashiCorp relicensed all its products, Nomad included, from the open-source MPL to the Business Source License (BSL) 1.1, which is source-available, not OSI open source. Then, in a deal that closed on February 27, 2025, IBM acquired HashiCorp for $6.4 billion. So betting your platform on Nomad today is betting on a source-available license and on IBM's roadmap for it, whereas Kubernetes remains under neutral CNCF governance that no single vendor controls.

That is not a reason to avoid Nomad. It's a reason to make the choice with open eyes: the lighter orchestrator's real cost isn't technical, it's strategic. You're trading a giant vendor-neutral ecosystem for a smaller, simpler tool whose future now runs through IBM. For some teams that's fine, plenty of critical infrastructure is vendor-owned. But it belongs in the decision, and most "Nomad is simpler" takes leave it out.

So, do you need the cluster?

Strip it down to who should pick what.

Reach for Nomad when your platform team is small and you'd rather operate one binary than a control plane; when your workloads are mixed, containers next to VMs, JARs, and raw executables that would be miserable to force into pods; when you're running on-prem or at the edge where a full managed cluster is overkill; and when operational simplicity is worth more to you than ecosystem breadth. If you can't point at a specific Kubernetes feature your system depends on, this is very likely you.

Stay on Kubernetes when you're actually buying the ecosystem, the operators, the Helm charts, the service-mesh options, the managed control planes on every cloud; when you're hiring at a scale where a universal skill set matters; when your workloads are cloud-native containers and you want the network effects of the industry standard; or when vendor-neutral governance is itself a requirement you can't compromise. "Everyone else runs it" is a weak reason on its own, but "we depend on ten things from its ecosystem" is a strong one.

The mistake in both directions is the same: choosing the orchestrator for a reason that isn't about your workload. Picking Kubernetes because it's the default, when you run twenty services and no ecosystem dependencies, buys you a distributed control plane you'll spend real time feeding. Picking Nomad to be contrarian, when you actually lean on half the CNCF landscape, trades a thriving ecosystem for a simplicity you didn't need and a license question you now own.

The honest version

"You don't need the cluster" is true far more often than the industry admits. A large share of Kubernetes adoptions are buying the reflex and the resume line, not solving a control-plane problem, and for those teams a single Nomad binary would run the same workloads with a fraction of the operational weight, and orchestrate the legacy stuff Kubernetes never wanted to touch besides.

But the reason to think hard in 2026 isn't only the ops surface. It's that the decision has quietly become a bet on governance: a neutral, vendor-owned-by-nobody Kubernetes with the biggest ecosystem in the field, against a lighter, cleaner Nomad that is now source-available and owned by IBM. Choose the scheduler your workloads and your team actually fit, weigh the ecosystem and the ownership honestly, and ignore the conference-talk gravity entirely. The right answer is a lot more often "not the cluster" than most teams are willing to say out loud.

Originally published at andriiboyko.com.
PS: English is not my native language, so I used AI to help with proofreading and phrasing. All ideas and technical content are my own.

REST, GraphQL, or gRPC: Picking the Right One Per Boundary, Not Per Company

Andrii B. — Sun, 30 Aug 2026 13:09:00 +0000

Somewhere in most engineering orgs there's a sentence that quietly did a lot of damage: "we're a GraphQL shop." Or a gRPC shop, or a REST shop. It sounds like discipline, like a team that made a decision and stuck to it. It's actually a category error, because the protocol was never a property of your company. It's a property of each boundary, and a single healthy system will rightly speak all three, one at each edge, for reasons that have nothing to do with taste.

REST, GraphQL, and gRPC are not three answers to one question. They're good answers to three different questions, and the questions are set by who's standing on the other side of the wire. Pick per boundary and each edge gets the thing that fits. Pick per company and you spend the next three years paying your chosen protocol's weakness at every edge where it was the wrong call.

The protocol is a property of the boundary

Here's the reframe that makes the whole decision easy. Before you argue about protocols, look at the boundary and answer four questions about it.

Who's on the other side? The public internet? A browser or mobile app you also build? Another team's service inside your own network? A third party you'll never meet? Each of these wants something different, and "other team's internal service" and "some developer integrating your public API" are about as different as two consumers get.

Do you own both ends? This is the big one. If you control the client and the server, you can use a strict binary contract and change both sides together. If you don't, you need something forgiving, debuggable, and standard, because the other end is out of your reach and will break in ways you can't fix.

What shape is the traffic? One request, one response? A client that needs many different slices of related data? A long-lived stream of updates? The shape of the conversation rules some protocols in and others out before you've written a line.

What do you need from the transport itself? Cacheability at the HTTP layer? The ability to curl it at 3am and read the response with your eyes? Raw throughput? A schema the compiler enforces? These aren't nice-to-haves; each one points at a different protocol.

Answer those four about a specific edge and the choice mostly makes itself. Answer them once for the whole company and you've guaranteed a bad fit somewhere.

The three, honestly

Skip the feature matrices. Here's what each one is actually best at, and the bill that comes with it, because the bill is where teams get surprised.

REST is the language of the open web, and its superpower is that everyone already speaks it. It rides plain HTTP, so you get caching, proxies, CDNs, browser support, and curl for free, and any developer on earth can integrate it without a toolchain. That's exactly why it's the right default for public and third-party APIs: the other side is a stranger, and REST asks nothing of them. The bill is that REST has no opinion about your data shape, so clients over-fetch (you return the whole user when they wanted a name) or under-fetch (they call three endpoints to assemble one screen), and without something like OpenAPI bolted on, there's no contract the compiler checks. For a public API those costs are worth paying. Between two of your own services, they're just friction.

GraphQL's superpower is letting many different clients ask for exactly the data they need from one schema. When you own a web app, an iOS app, and an Android app, and all three want overlapping-but-different slices of the same graph, GraphQL kills the over/under-fetching problem dead: each client sends one query for precisely its fields.

# One round trip, exactly the fields this screen needs. No more, no less.
query {
  user(id: "u_42") {
    name
    orders(last: 3) { id total status }
  }
}

That's a genuinely great fit for the client-to-backend edge, the classic backend-for-frontend. The bill is real, though: HTTP caching mostly goes out the window (one endpoint, POST bodies), you invite the N+1 problem and have to solve it with dataloaders, and you take on a schema-and-resolver layer plus query-cost and abuse concerns. Between two internal services that always want the same fixed payload, that whole apparatus is machinery you're maintaining for flexibility nobody's using.

gRPC's superpower is speed and a contract the compiler enforces, over a connection you control on both ends. It serializes with Protocol Buffers (compact binary, not text) over HTTP/2, and in common benchmarks it runs several times faster than JSON-over-HTTP while giving you real streaming, server, client, and bidirectional, plus a .proto file that generates typed clients and servers in every language.

// The contract IS the source of truth. Both sides generate from it.
service Orders {
  rpc GetOrder(GetOrderRequest) returns (Order);
  rpc WatchOrders(WatchRequest) returns (stream Order); // server streaming
}

This is the right call for internal service-to-service traffic where you own both ends, care about latency and throughput, and want a strict schema. The bill: it isn't native to browsers (they can't speak raw gRPC, so you need gRPC-Web or Connect, and true bidirectional streaming still doesn't work from a browser as of 2026), the binary payloads are harder to eyeball, and it adds proxy and infra friction. Point it at the public internet and you've handed every integrator a toolchain problem to solve your performance problem.

The map, drawn once

Put the four questions and the three bills together and the boundary map is almost boring in how clearly it falls out:

Public or third-party API (strangers, you don't own their end): REST. Reach for GraphQL here only if your public consumers genuinely need to shape their own queries over a rich graph, which is rarer than it sounds.
Your own browser and mobile clients talking to your edge (you own both, many different slices): GraphQL, as a backend-for-frontend. Plain REST is a perfectly good answer too when the clients are simple; don't add a graph you don't need.
Internal service-to-service, you own both ends, latency and contracts matter: gRPC. This is its home turf and nothing else comes close.
Streaming updates: gRPC streaming if it's inside your walls; for browser-facing streams, server-sent events or websockets, or a messaging system if it's really events rather than calls.

And one modern wrinkle worth knowing: the Connect protocol (from Buf) was built specifically to stop forcing this into either-or at the client edge. It's a POST-based protocol that works over HTTP/1.1 or HTTP/2, speaks JSON or binary, runs in browsers and between services, and stays compatible with gRPC. If your pain is "I want one Protobuf schema from the browser all the way down to the services," Connect is the thing that lets a single contract span that whole path without a gRPC-Web translation layer bolted on the side.

One request, three protocols

Here's what "per boundary" looks like in a single trace, and why it isn't chaos. A user opens your web app. The browser sends one GraphQL query to your backend-for-frontend, asking for exactly the fields that screen needs. The BFF fans that out to three internal services over gRPC, because those are your services, on your network, and you want them fast and strictly typed. One of those services needs a shipping quote, so it calls a logistics partner's public REST API, because that partner is a stranger and REST is the only thing you can assume they expose.

Three protocols, one user action, and every hop used the right one for its edge. Nobody had to "win." A gRPC absolutist would be fighting the browser at the top of that trace; a GraphQL absolutist would be running a schema-and-resolver layer between services that only ever exchange fixed payloads; a REST absolutist would be making chatty, uncached, contract-less internal calls where gRPC would have been faster and safer. The polyglot version isn't a compromise. It's each boundary getting what it actually needs.

Why "per company" is the actual anti-pattern

It's worth being precise about why standardizing one protocol everywhere goes wrong, because it always sounds so responsible in the meeting.

When you mandate gRPC everywhere, you spend real effort dragging it somewhere it doesn't belong: the browser. Now every frontend needs gRPC-Web or a proxy, your public integrators need a toolchain to call you, and you're maintaining translation layers to paper over the fact that browsers don't speak your chosen protocol.

When you mandate GraphQL everywhere, you install a schema-and-resolver layer between internal services that exchange fixed, well-known payloads and never needed query flexibility. You gave up HTTP caching, invited N+1 into paths that were simple request-response, and added query-cost policing to service-to-service calls that could have been a typed gRPC method.

When you mandate REST everywhere, your internal calls are chatty and uncached, you have no compiler-checked contract between services that deploy independently, and you're hand-rolling streaming over a protocol that would rather you didn't.

Every one of those is the same mistake: taking a tool that's excellent at one kind of boundary and forcing it onto boundaries it was never good at, in the name of a consistency that only helps the org chart, not the system.

The senior move

The instinct to standardize comes from a good place, fewer things to learn, one way to do it, less sprawl. And inside a single boundary, that instinct is right: pick one protocol for your public API and hold the line; pick one for your service mesh and don't have three. Consistency within a boundary is a real virtue.

The mistake is stretching that consistency across boundaries that have nothing in common except that they're yours. The public internet and your internal service mesh are not the same problem, and the same protocol cannot be the best answer to both. The senior move isn't picking a winner. It's refusing to, and instead asking, at each edge, the four questions that actually decide it: who's on the other side, do I own both ends, what shape is the traffic, what do I need from the transport. Answer those honestly per boundary, let your system be polyglot on purpose, and the protocol war just stops being a war you have to fight.

Originally published at andriiboyko.com.

A2A vs MCP: What Agent-to-Agent Actually Adds Over Tool Calling

Andrii B. — Mon, 17 Aug 2026 15:50:54 +0000

The question "should I use A2A or MCP" is the wrong question, and asking it out loud is a decent early sign you don't need A2A yet. They aren't two options on the same shelf. One connects your agent down to its tools; the other connects your agent sideways to other agents. You can run both, neither, or one without the other, and for most teams the honest answer is "MCP, and not A2A, at least not this quarter."

But that's a boring answer, and it hides the interesting part. Because when A2A does earn its place, it's not adding "collaboration" in some fuzzy marketing sense. It's adding three specific, mechanical things that a tool call cannot give you, and all three come from the same root: A2A is built to talk to an agent you don't own and can't see inside. Let's pin down what that actually buys you, and when it's worth the protocol.

Two different axes, not two options

Start with where each one sits, because the whole confusion is a category error.

MCP (the Model Context Protocol) is Anthropic's standard, released in late 2024, for how a single agent reaches its tools and context: databases, APIs, files, a search index. It defines a few primitives (tools, resources, prompts), speaks JSON-RPC, and its mental model is vertical. Your agent is at the top; the things it can call are underneath it. Crucially, your agent can enumerate those tools. It knows their names, their input schemas, their output shapes. A tool is, in A2A's own words, a "primitive with well-defined, structured inputs and outputs" doing a "specific, often stateless" job.

A2A (Agent2Agent) is a protocol Google introduced in April 2025 and handed to the Linux Foundation a couple of months later, where it now lives as a vendor-neutral project. Its mental model is horizontal. Your agent talks to other agents as peers. And the defining word in A2A's own framing is "opaque": the other agent is an autonomous system that "reasons, plans, uses multiple tools, maintains state over longer interactions," and it does all of that without showing you any of it. You don't see its tools. You don't see its prompt. You don't see its memory. You hand it a task and deal with it as a black box.

So the picture isn't "A2A vs MCP." It's an agent with a vertical line down to its own tools (MCP) and horizontal lines out to other agents (A2A). A serious multi-agent deployment often runs both: A2A to reach other agents, MCP inside each agent to reach its own tools.

The baseline: what a tool call already gives you

Before naming what A2A adds, be honest about how much a plain tool call already does, because it's a lot, and it's the thing you should reach for first.

When your agent calls a tool (whether you wired it by hand or through MCP), you get a clean contract. There's a name and a JSON schema. The call is usually synchronous: you ask, you block, you get a structured result or an error. You own both sides, so you can change the schema, add a field, fix a bug, and redeploy. The type system is right there. If the tool returns the wrong shape, you find out immediately, in your own codebase.

// An MCP-style tool: a contract you own and can enumerate
{
  "name": "get_order",
  "description": "Fetch an order by id",
  "inputSchema": {
    "type": "object",
    "properties": { "order_id": { "type": "string" } },
    "required": ["order_id"]
  }
}

That's the baseline. It's simple, it's typed, it's synchronous, and it's yours. Ninety percent of "let my agent do X" is exactly this, and adding a second agent protocol on top would be pure overhead. So the bar for A2A isn't "does it help agents work together." The bar is "does my problem have a shape that a tool call genuinely can't hold." Here's when it does.

What A2A actually adds

Three things, and they're a package deal because they all fall out of the same design goal: talking to an agent you can't see into.

1. Opacity, on purpose. With a tool, you see the whole contract. With A2A, you don't, and that's the feature, not a gap. The remote agent advertises what it can do through an Agent Card, a small JSON document describing its identity, skills, endpoint, and auth, but nothing about how. You never learn its internal tools or reasoning. Why would you want less visibility? Because the other agent belongs to another team, another company, or another trust boundary, and coupling to its internals would be exactly the mistake you spent years learning not to make with microservices. A2A makes the black box the unit of integration.

// An A2A Agent Card: capability advertisement, no internals leaked
{
  "name": "Fraud Review Agent",
  "description": "Reviews a transaction and returns a risk decision",
  "url": "https://risk.acme.com/a2a",
  "version": "1.4.0",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "skills": [
    { "id": "review_transaction", "description": "Assess a transaction for fraud risk" }
  ]
}

2. Long-running, stateful tasks instead of a blocking call. A tool call is a function: it returns, and it's over. A lot of real agent work isn't shaped like that. It runs for minutes, hours, or across a human approval step. A2A models this as a Task with a lifecycle: it moves through states like submitted, working, input-required, and finally completed or failed. You send a message, the call returns immediately with a Task that's still working, and the agent keeps going in the background. You get progress three ways: synchronous polling, a Server-Sent Events stream for live updates, or push notifications to a webhook when the whole thing is disconnected and long. Try expressing "start this, it'll take an hour, ping my webhook when the human approves" as a single tool call. You can't, cleanly. That's a Task.

// message/send returns a Task that is still running, not a final answer
{
  "jsonrpc": "2.0", "id": 1, "method": "message/send",
  "params": {
    "message": {
      "role": "user",
      "parts": [{ "kind": "text", "text": "Review transaction tx_88213" }]
    }
  }
}
// -> Task { "id": "t_9f2", "status": { "state": "working" } }
// later: poll tasks/get, or receive a push notification, or read the stream

3. Discovery, so you don't hardwire the other side. With tools, you know at build time exactly what's available; you wrote them in. A2A agents publish Agent Cards, so a client can discover a capable peer and negotiate with it, including which content types and modalities both sides speak. It's the difference between calling a function you imported and finding a service that advertises it can do the job. That only matters across a boundary where you don't control, or don't want to control, the full catalogue up front.

The boundary is the whole point

Read those three back and notice they're the same idea wearing three hats. Opacity, long-running tasks, and discovery are all answers to one situation: the other agent is not yours. It's another team's service, a vendor's product, a partner's system. You can't import its functions, you shouldn't see its internals, and it doesn't finish on your request's timeline.

That's the real test, and it's a lot sharper than "do I have multiple agents." You can absolutely have five agents in one codebase, all yours, and the right way to connect them is still boring function calls or MCP, because you own them, you can enumerate them, and a typed call beats a network protocol every time you can have one. Putting A2A between two agents you control is the classic over-engineering move: you've traded a compile-time-checked call for an opaque JSON-RPC round trip and gotten nothing back, because the opacity you're paying for is protecting you from a boundary that doesn't exist.

A2A earns its keep exactly at the org chart's edges. Your agent needs a risk decision from the fraud team's agent, and that team ships on their own cadence and won't hand you their internals. You integrate a vendor's research agent you literally cannot see inside. A partner exposes a booking agent and you negotiate over A2A. In every case the thing you actually needed wasn't "collaboration." It was a stable seam between systems that don't, and shouldn't, know each other's guts.

So which do you reach for?

Here's the decision, stripped down.

Default to a tool call, and use MCP to standardize it when you have more than a couple of tools or want them reusable across agents. This covers the overwhelming majority of "make my agent able to do X." It's typed, synchronous, and yours.

Reach for A2A when the other side is an agent you don't own or can't see into, when the work is long-running or needs a human in the loop across time, or when you need to discover and negotiate with a capable peer rather than hardwire it. If none of those is true, you're adding a protocol to solve a problem you don't have.

And know that they compose, because that's the setup you'll actually run once you're past one agent. A2A's own docs use an auto-repair-shop example: the customer talks to the shop's manager agent over A2A, the manager delegates to a mechanic agent over A2A, and the mechanic reaches its diagnostic tools over MCP. Outward across boundaries, A2A. Inward to your own tools, MCP. The agent is the same thing on both sides; only the axis changes.

The one question

Strip away the protocol names and the layer diagrams and you're left with a single question that decides everything: is the agent I'm calling mine?

If it is, keep it simple. Call the function, wire the tool, standardize with MCP when the toolset grows. You keep your types, your synchronous flow, and the ability to fix both sides at once. If it isn't, that's the moment A2A stops being overhead and starts being the thing that lets two systems you don't jointly control actually work together, without either one reaching into the other.

"A2A vs MCP" was never the real question. The real one is where your boundaries are, and whether the agent on the other side of one is a black box by accident or by design. Get that right and the protocol picks itself.

PS: English is not my native language, so I used AI to help with proofreading and phrasing. All ideas and technical content are my own.
Originally published at andriiboyko.com.

Restate's Single Binary vs Temporal's Cluster: When the Lighter Engine Wins

Andrii B. — Sun, 09 Aug 2026 19:05:41 +0000

Correction note (September 2026): Maxim Fateev, co-founder of Temporal, pointed out several factual errors in the original version. I have corrected the sections on Cassandra, TypeScript determinism, and Restate's replay model. His full comment is in the discussion below, and I recommend reading it. Many thanks to him for taking the time to read the article this closely and write up these corrections.

Here is a bet that will save you a lot of arguing: pick your durable execution engine on what you have to operate, not on what you have to write. The code you write for Restate and the code you write for Temporal end up looking more alike than either vendor wants to admit. They both journal every step and replay it after a crash so your half-finished order doesn't get charged twice. What actually differs, and what you'll be living with at 2am, is the shape of the thing you have to run. One is a single binary. The other is a cluster of four services with an external database bolted to the side.

That's the whole article in one sentence, but the sentence hides all the interesting parts: when the cluster is exactly what you want, when it's a tax you're paying for nothing, and why "single binary" isn't quite as simple as it sounds either. Let's get specific, because the marketing on both sides is loud and the honest version is more useful.

The same problem both are solving

Durable execution is a narrow, beautiful idea. Your code runs a multi-step operation: charge the card, reserve the inventory, send the email, mark the order shipped. Halfway through, the process dies. A normal service loses everything in memory and you're left reconciling a card that got charged against inventory that never got reserved. A durable execution engine writes each completed step to a journal, and when the process comes back it replays that journal, skips the steps that already finished, and continues from exactly where it stopped. No double charge, no lost reservation.

Both Restate and Temporal do this. Both do it well. So the first thing to throw out is any pitch that frames one as "durable" and the other as "less durable." They are both real durable execution engines built on journal-and-replay. If someone is selling you on durability itself as the differentiator, they're selling you the thing you get from either one. The differentiator is everything around the journal: where it lives, what runs it, and what your app has to become to use it.

Temporal is a cluster, and your app becomes two services

Temporal's server is not one process. It's four independently scalable services: a Frontend that acts as the gateway (routing, rate limiting, auth), a History service that owns the mutable workflow state and timers, a Matching service that hosts the task queues that dispatch work, and an internal Worker service for Temporal's own system workflows. Each is a separate process with its own gRPC endpoint, and the whole point of splitting them is that you scale them independently when you're big enough to need that.

That cluster can't remember anything on its own. It requires an external database for persistence: PostgreSQL or MySQL in practice (SQLite exists for local dev). Cassandra is still supported as a persistence store. What was deprecated in Server v1.21 and removed in v1.24 was standard Visibility, which was the only Visibility mode Cassandra ever supported. So Cassandra works for persistence, just not for the current Visibility model. And once you spawn more than a handful of workflows and want to search them by anything richer than an ID, you're looking at Elasticsearch or OpenSearch. That last one is a genuine nuance the internet gets wrong in both directions: SQL databases have supported Advanced Visibility since Server v1.20, so Elasticsearch is not strictly required. It's recommended once your volume grows. "Temporal always needs Elasticsearch" is a myth; "you'll probably want it eventually" is the truth.

Then there's your own code. In Temporal, your workflow logic runs inside a Worker, a process that hosts your workflow and activity code and long-polls the cluster's task queues for work. That worker is a separate deployable from your API. So adopting Temporal isn't just "run a server." It's: stand up the cluster, attach a database, probably add a search cluster later, and split your application into an API service plus a worker service that both depend on the Temporal server being up. Here's the shape of the code that runs in that worker:

// activities.ts - the side effects, retryable, run in a normal runtime
export async function greet(name: string): Promise<string> {
  return `Hello, ${name}!`;
}

// workflows.ts - orchestration, and it must be deterministic
import { proxyActivities } from '@temporalio/workflow';
import type * as activities from './activities';

const { greet } = proxyActivities<typeof activities>({
  startToCloseTimeout: '1 minute',
});

export async function example(name: string): Promise<string> {
  return await greet(name);
}

Notice you don't call greet directly from the workflow. You go through proxyActivities, because the workflow code is replayed from its event history on every recovery and must be deterministic: the same input has to produce the same sequence of commands every time, or Temporal raises a nondeterminism error and refuses to continue. That constraint is the price of Temporal's replay model, and how much you feel it depends on the SDK. In Go and Java you design around it by hand. The TypeScript SDK runs each workflow in a V8 isolate sandbox where Date, Math.random() and setTimeout() are replaced with deterministic versions, so in the code above you can call them directly and replay stays correct. The contract is still there, the sandbox just enforces it for you. Temporal Cloud exists precisely so you don't have to run the cluster and database yourself, and if you're going to commit to Temporal at scale, paying them to operate it is usually the sane choice.

Restate is one binary, and the database is already inside it

Restate takes the opposite bet. The server is a single binary written in Rust with a stream-processing architecture, and it carries its own storage: an embedded RocksDB key-value store holds the journal and the durable state. There is no external Postgres to provision, no Elasticsearch to babysit. You download one binary, you run it, and you have durable execution.

The honest asterisk, because Restate's own comparison page glosses over it: "single binary" does not mean "single process and nothing else" once you care about high availability. For HA you run several instances of that binary, and RocksDB periodically snapshots to an object store (S3, GCS, or Azure Blob) so a node can fail and another can recover the state and trim its logs. So the real comparison isn't "one process vs a cluster." It's "several copies of one binary plus a bucket" versus "four service types plus a relational database plus an optional search cluster plus your own split-out worker." That's still a dramatic difference in operational surface, but say it accurately or someone will call your bluff in the comments.

The programming model is ordinary-looking service handlers that Restate journals for you:

import * as restate from "@restatedev/restate-sdk";

export const myService = restate.service({
  name: "MyService",
  handlers: {
    myHandler: async (ctx: restate.Context, greeting: string) => {
      return `${greeting}!`;
    },
  },
});

restate.serve({ services: [myService] });

Restate's distinctive primitive is the Virtual Object: a stateful entity keyed by an id, with its own isolated key-value state and a single-writer guarantee, so only one handler mutates a given object's state at a time. It's durable keyed state without you standing up a separate store for it:

import * as restate from "@restatedev/restate-sdk";

export const myObject = restate.object({
  name: "MyObject",
  handlers: {
    myHandler: async (ctx: restate.ObjectContext, greeting: string) => {
      return `${greeting} ${ctx.key}!`;
    },
  },
});

restate.serve({ services: [myObject] });

Restate also gives you durable promises (awakeables) to wait on external events, and durable timers via ctx.sleep, all tracked across failures. It has SDKs for TypeScript, Java and Kotlin, Python, Go, and Rust. The replay mechanism is the same idea: Restate re-runs the handler from the start and skips steps already in the journal, so code outside those steps has to be deterministic here too. Restate's own docs list Math.random(), new Date() and iterating unordered collections as causes of journal mismatch errors. The difference is ergonomic, not contractual: a side effect goes inline through ctx.run in the same function instead of into an activity in a separate deployable. Both position themselves as durable execution platforms rather than workflow engines, and both point at use cases well beyond orchestration.

The programming models diverge more than the marketing admits

It's tempting to say "they're both durable execution, the code is basically the same." It isn't, and the difference is exactly the kind of thing that bites you six months in.

Temporal's model is a hard split between deterministic workflows and side-effecting activities, enforced by replay. That split is powerful: it's what lets a workflow sleep for thirty days and wake up with its local variables intact, because Temporal isn't keeping your process alive, it's replaying your workflow's event history to reconstruct that state on demand. But it means your orchestration code lives under a determinism microscope. Every nondeterministic thing you're used to reaching for is a landmine, and "why did my workflow throw a nondeterminism error after I changed the code" is a rite of passage.

Restate's model asks less of your mental model up front: you write handlers, you use the context for the durable operations, and durable keyed state lives in a Virtual Object instead of a workflow-scoped variable. For a lot of backend work, "make this handler crash-proof and give it some durable state" is all you wanted, and you get it without adopting the full workflow-orchestration worldview. The flip side: Temporal's worldview, once you've paid for it, is genuinely better at the gnarliest long-running orchestration, and its retry and timeout configuration is deeper.

So how much of this is code, and how much is ops?

This is where the "mostly ops, not code" claim earns or loses its keep. The code delta is real but modest: with either engine you annotate or restructure some functions and route durable steps through a context. The operational delta is not modest at all.

There's a widely-cited number here, and it's worth handling honestly because it's easy to misuse. DBOS, which is itself a competitor to both, published a benchmark where adopting Temporal on a sample app meant changing more than 100 lines, growing the app from 110 to 187 total lines, and splitting it into two services (a worker and the API) with a runtime dependency on a third (the Temporal server), three tightly-coupled services where any one going down takes the other two with it. That's a vendor's benchmark of DBOS versus Temporal, on one sample app, so don't quote it as a law of nature and definitely don't attribute it to Restate. But the architectural claim underneath it is neutral and verifiable straight from Temporal's own docs: your workflow code runs in a separate worker deployable, and the cluster plus its database are separate infrastructure. That part isn't marketing. It's how Temporal is built.

For Restate versus Temporal specifically, I couldn't find a clean neutral lines-of-code comparison, so I won't invent one. What I can say from the architecture is the honest version: standing up Restate is downloading a binary and pointing it at an object store; standing up Temporal is running a four-service cluster, attaching Postgres, planning for a search cluster, and splitting your app into API-plus-worker. If your instinct is that those are not remotely the same amount of ops, your instinct is correct, and no amount of "but Temporal Cloud makes it easy" changes the fact that you either run all of that or pay someone to.

When the heavier engine earns it

None of this means Temporal is overkill. It means Temporal is priced for a specific job, and when you have that job, the cluster is a bargain.

Reach for Temporal when your workflows are genuinely long and human-timescale: things that sleep for days, weeks, or months and must survive every deploy and restart in between. Reach for it when you need deep, per-activity control over retries and multiple timeout types, when you want the largest ecosystem and the most battle-tested SDKs across TypeScript, Java, Python, Go, .NET, and PHP, and when scale and multi-region operation are real requirements rather than aspirations. Two things matter here: Temporal Cloud gives you managed multi-region so you're not operating that cluster yourself, and Temporal Nexus is now generally available, which lets teams compose durable executions across isolated namespaces, regions, and clouds with per-team blast-radius isolation. If your problem is "twelve teams each own a namespace and need to call each other's durable workflows without sharing a database," that's a Temporal-shaped problem, and Restate isn't trying to be the answer to it.

When the lighter engine wins

Here's the part the title promised. The lighter engine wins far more often than the "we're an enterprise, we need Temporal" reflex assumes.

Restate wins when your durable needs are "don't lose this multi-step operation and give it some durable state," not "orchestrate month-long sagas across a dozen teams." It wins when the operational budget is the constraint, when a single binary plus an object store is a Tuesday and a four-service cluster plus a database plus a search cluster is a quarter of platform work you didn't want to fund. It wins when you want durable execution to sit inside your normal backend, your services, your event handlers, the agent you're building this year, rather than forcing everything through a workflow-orchestration frame. And it wins on adoption speed: the fastest way to have durable execution running in an afternoon is the one that doesn't start with provisioning a cluster.

So the verdict, stated as a decision rule you can actually use: default to the lighter footprint, and only take on Temporal's cluster when you can name the specific Temporal feature you need that Restate doesn't give you. Month-long timers with per-step retry policies. Cross-namespace composition through Nexus. Battle-tested operation at a scale you're actually at, not the scale on your roadmap. Those are real reasons, and when they're your reasons, pay the operational tax gladly. But if you're standing up a Postgres, an Elasticsearch, and a two-service split to make a five-step checkout crash-proof, the engine isn't the thing that's overbuilt. The decision was. Both of these journal and replay. Pick the one whose operations page you'd actually enjoy owning.

PS: English is not my native language, so I used AI to help with proofreading and phrasing. All ideas and technical content are my own.

Originally published at andriiboyko.com.

If you found this helpful, follow me here and on LinkedIn

You Probably Don't Need a Dedicated Vector Database

Andrii B. — Fri, 07 Aug 2026 09:44:00 +0000

Somewhere in the last two years, "we're doing RAG" quietly became "so we need a vector database," and the second half of that sentence stopped getting questioned. You add Pinecone or Qdrant or Weaviate to the stack, wire up a sync job, and now you own two datastores that have to agree with each other forever. For a demo, fine. For most production systems, you just bought a distributed-systems problem to solve a problem you didn't have.

Here's the number that should have ended the debate before it started: pgvector, the vector extension that runs inside the Postgres you're already paying for, handles vector search comfortably into the low tens of millions of vectors on a single node. Not "for toy projects." Into the tens of millions. And it does it while your embeddings sit in the same transaction, the same backup, and the same WHERE tenant_id = ? as the rest of your data. The dedicated vector database is a real tool with a real job. That job just starts a lot further up the scale curve than the people selling it want you to think.

What a vector database actually does

Strip away the marketing and a vector database does one thing: approximate nearest-neighbor search over high-dimensional embeddings. You have a query vector, you have millions of stored vectors, and you want the closest few by cosine or L2 distance without comparing against every single one. The trick that makes it fast is an index, almost always HNSW (Hierarchical Navigable Small World), a graph you walk to find close neighbors in roughly logarithmic time instead of scanning the whole set.

That's it. That's the special sauce. And Postgres has had it since pgvector 0.5.0 shipped HNSW back in 2023. Here's the entire "vector database" you need for most apps:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
  id         bigserial PRIMARY KEY,
  doc_id     bigint NOT NULL REFERENCES documents(id),
  tenant_id  bigint NOT NULL,
  content    text,
  embedding  vector(1536)          -- e.g. OpenAI text-embedding-3-small
);

-- The index that makes it fast. m and ef_construction trade build time for recall.
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

A nearest-neighbor query is an ORDER BY on a distance operator (<=> is cosine distance, <-> is L2, <#> is negative inner product):

SELECT id, content
FROM chunks
ORDER BY embedding <=> $1     -- $1 is your query embedding
LIMIT 10;

That query, against an HNSW index that fits in memory, is not meaningfully slower than the same query against Pinecone at the scales most teams operate at. Benchmarks have pgvector with HNSW matching or beating dedicated engines at around 1M vectors. So the honest question isn't "is pgvector good enough" at a million vectors. It obviously is. The question is what you give up by not adding a second system, and the answer is: nothing. You gain things.

The stuff you get for free (and would have to rebuild)

This is the part the comparison charts leave out, because it doesn't fit in a QPS column. When your vectors live in Postgres, every other thing Postgres does applies to them at the same time.

Filtering and multi-tenancy are just a WHERE clause. Real RAG is almost never "search all vectors." It's "search this tenant's documents," or "search docs this user can see, from the last 90 days, in the 'published' state." In Postgres that's the query you already know how to write, and it runs in the same index scan:

SELECT c.id, d.title, c.content
FROM chunks c
JOIN documents d ON d.id = c.doc_id
WHERE c.tenant_id = $1
  AND d.status = 'published'
ORDER BY c.embedding <=> $2
LIMIT 10;

Look at that JOIN. Your embedding result comes back already stitched to the document's title, its author, its permissions, whatever you need, in one round trip. In a dedicated vector store you get back a list of IDs, and then you make a second call to Postgres to hydrate them, and now you're doing a distributed join by hand in application code and hoping the two systems didn't drift.

Row-level security means tenant isolation you can't forget. You can push tenancy down into the database so a missing WHERE clause can't leak one customer's chunks into another's results:

ALTER TABLE chunks ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON chunks
  USING (tenant_id = current_setting('app.tenant_id')::bigint);

Try enforcing that in a separate vector database. You can't, really, not at the storage layer. Tenant isolation becomes an application concern you re-implement and re-audit, which is exactly the kind of thing that turns into a security incident.

One transaction, one backup, one truth. When you insert a document and its chunks and their embeddings, that's one transaction. It commits or it doesn't. There's no window where the document exists but its vectors don't, or where you deleted a record but its embedding is still floating in another system returning ghosts in search. Your existing backup, your existing replica, your existing point-in-time recovery already cover the vectors. You didn't add an operational surface. You added a column.

That "one truth" point is the whole argument, honestly. The moment you split vectors into their own store, you own a synchronization problem: dual writes, eventual consistency between your source of truth and your search index, reconciliation jobs, and the 3am question of why a deleted record still shows up in RAG results. That problem is real work, and you took it on to save a latency difference you can't measure yet.

The two gotchas that actually bite

pgvector is not magic, and pretending it has no sharp edges is how you end up back in the dedicated-database camp for the wrong reasons. There are exactly two things that bite people, and both have answers.

Gotcha one: the HNSW index has to fit in memory. The single biggest factor in pgvector performance is whether the HNSW graph lives in RAM. When the index fits in shared_buffers and stays there, queries are fast and boring. When it spills to disk because the index outgrew memory or got evicted under load, tail latency falls off a cliff. So capacity-planning pgvector is really memory-planning: know your vector count times your dimensions times the index overhead, and make sure it fits with headroom. A 1536-dimension vector is about 6KB raw; ten million of them plus HNSW overhead is a real but very ordinary amount of RAM for a database server in 2026. This is also where halfvec earns its keep: store embeddings as 16-bit floats and you roughly halve the memory, which for 3072-dimension models is the difference between fitting and not.

Gotcha two: filtered search used to quietly return too few rows. This one burned people for years and is the single most common "pgvector is broken" complaint. Before pgvector 0.8.0, the HNSW index returned its candidate set first, and then your WHERE tenant_id = ? filter ran on that set. If your filter was selective, you'd ask for 10 results and get 3, because 7 of the index's candidates belonged to other tenants and got dropped after the fact. It looked like a correctness bug and it was really an ordering-of-operations problem.

pgvector 0.8.0 fixed it with iterative index scans: the planner keeps pulling more of the index until enough rows survive your filter. You turn it on per-session:

SET hnsw.iterative_scan = relaxed_order;   -- keep scanning until LIMIT is satisfied
-- strict_order preserves exact distance order; relaxed_order trades a little
-- ordering for better recall under selective filters.
-- Bounds: hnsw.max_scan_tuples (default 20000), hnsw.scan_mem_multiplier (default 1).

SELECT id, content
FROM chunks
WHERE tenant_id = $1
ORDER BY embedding <=> $2
LIMIT 10;

If you evaluated pgvector before 0.8.0, hit the filtered-search wall, and concluded you needed a "real" vector database, that conclusion is now out of date. Re-check it. The version number matters here more than almost anywhere else in the Postgres world.

When you actually do need one

The contrarian take isn't "never use a dedicated vector database." It's "know the line, and don't cross it before you get there." The line is real, and it's roughly this:

Under roughly 10 million vectors, pgvector with a well-tuned HNSW index that fits in RAM matches or beats dedicated engines, and you keep all the free stuff above. From about 10 to 50 million, plain pgvector starts to strain, but you don't have to leave Postgres yet: the pgvectorscale extension adds a StreamingDiskANN index that stays fast when the dataset is larger than RAM, plus statistical binary quantization to shrink memory and label-aware filtering. In one benchmark it hit 471 queries per second at 99% recall on 50 million vectors, about 11 times Qdrant's throughput at the same recall. So the "you'll outgrow Postgres" story has a whole extra chapter before it's even true.

Past 50 to 100 million vectors, or when your workload is vector-search-first with brutal tail-latency SLAs and you want someone else to operate the scaling, the dedicated engines genuinely pull ahead. Pinecone is the fastest path to zero-ops scaling toward billions. Qdrant wins raw QPS and filtering if you want to stay open-source and run it yourself. Weaviate bundles embedding generation so you can hand it raw text. These are good products solving a real problem. They're just solving a problem that starts at a scale most applications will never reach, and they charge you the two-system tax the entire way there.

The mistake almost nobody regrets avoiding is starting on pgvector and migrating later. Moving 100 million vectors to a dedicated store when you actually hit the wall is a known, boring data-migration project you'll have the revenue to staff. Standing up a second stateful system on day one to serve 200,000 vectors is how you spend your scaling budget before you have anything to scale. Put the embeddings in the database that already holds your data, add the vector column, ship the feature, and add the dedicated engine the day the numbers, not the demo, tell you to.

Originally published at andriiboyko.com.

If you found this helpful, follow me here and on LinkedIn