Magento Open Source high availability guide

Magento Open Source high availability starts with the checkout path

High availability for a Magento Open Source store means separating the tiers, running more than one web node behind a load balancer, and keeping session, cache and database state where any node can reach it. A store that runs on one server or one combined stack can lose sales in full when that machine fails or when a peak arrives, so the first decision is to split web, database, search, cache, session and queue services onto components that can be scaled and replaced independently.

Checkout is the hardest path to make resilient because it depends on state that cannot be served from a cache. A shopper's cart, the session that identifies that cart, live stock reads during addresses and shipping calculation, and payment callbacks from the gateway all have to land on a node that sees the same data. If sessions are stored on one web node's local disk, a load balancer that routes the next request elsewhere will log the shopper out or empty the cart. Your team should confirm where sessions are stored (Redis or Valkey is the usual choice in Adobe's requirements), that every web node points to the same cache and session backends, and that payment callback URLs resolve to the public entry point rather than to one node.

A full-page cache alone does not make a store highly available. Varnish serves cached pages for anonymous browsing, which reduces load on PHP and the database during a traffic spike, but it does not cache cart, checkout or customer account pages, and it does not protect those paths when a web node or the database fails. Adobe documents Varnish as the full-page cache accelerator for self-managed installations, while cloud-hosted Adobe Commerce uses Fastly instead. Confirm which option applies to your hosting model before you design the cache tier, because the configuration, purge behavior and failover approach differ.

For planning, Adobe's requirements for Magento Open Source 2.4.9 list PHP 8.5, MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30 on Linux x86-64. For 2.4.8-p5, Adobe lists PHP 8.4 or 8.3, MySQL 8.4 or MariaDB 11.4 or 11.8, OpenSearch 3, Redis or Valkey 8.1, RabbitMQ 4.3, Composer 2.10, nginx 1.30 and Varnish 8. Adobe supports only the listed combinations, so use these as a reference for sizing and version planning and confirm the exact combination on Adobe's system requirements page before you order infrastructure or write a build plan.

Which Magento Open Source components an HA build separates

A high availability build splits Magento Open Source into separate tiers so that each one can be scaled, replaced or restored without taking the others down. Each tier holds a different kind of state, and sharing one of them across nodes incorrectly causes a different failure. The cards below list the supported services, what each one holds, and where the store is pointed at it.

Web tier with nginx and PHP-FPM

The web tier serves the storefront and admin through nginx and PHP-FPM. It holds no customer state of its own, but every node must run identical code and generated files, and the media and var directories must be on storage all nodes can reach. If nodes run different code versions, pages and admin screens behave differently from one node to the next. Point the load balancer at the nginx upstreams, and confirm PHP and nginx versions against the requirements for your chosen release, since 2.4.9 lists PHP 8.5 and nginx 1.30.

Database with optional replicas

The database holds orders, customers, catalog data and store configuration, so it is the record the store cannot rebuild. MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8 are listed for 2.4.9. Read replicas can offload reporting and some read traffic, but checkout writes must reach the primary. Connection details for the primary and any replica are set in the db section of app/etc/env.php. Confirm with your release notes how the platform routes reads to a replica before you rely on it during a peak.

Search with OpenSearch 3

The search tier holds the product search index, which indexers rebuild from catalog data. It does not hold customer records, so losing it affects findability rather than orders. The risk is nodes pointing at different clusters or serving an index that lags behind catalog changes, which shows shoppers different results. The engine host and port are set in the admin catalog search configuration, which is stored in the database rather than in env.php. Confirm the OpenSearch 3 requirement for your release before sizing the cluster.

Cache and sessions in Redis or Valkey

Shared cache and customer sessions live in Redis or Valkey, which is version 9 on 2.4.9 and 8.1 on 2.4.8-p5. Sessions held in files on one web node cause shoppers to be logged out or lose carts when the load balancer sends them elsewhere. Sharing one cache backend also keeps every node working from the same invalidated data. The session save handler and the cache backends are set in env.php, so check that each node reads the same host and database index.

Message queue with RabbitMQ 4.3

RabbitMQ 4.3 carries queued work such as asynchronous operations and messages used by integrations, depending on the modules and extensions you install. The queue holds messages that have not yet been processed, so its state matters during a broker restart. Consumers must be started in a controlled way, because running the same consumer on every node can process a message twice. Broker connection details are set in the queue section of env.php. List every consumer your extensions require before deciding where they run.

Full-page cache with Varnish 8

Varnish 8 is the full-page cache for self-managed installations, and it is listed for 2.4.8-p5. It stores rendered pages, so its rules decide what can be shared between shoppers. Caching personalized blocks or checkout pages can expose one shopper's data to another, and a missed invalidation after a price change shows stale prices. The backend hosts are set through http_cache_hosts in env.php, and the cache mode is set in the admin. Confirm the Varnish version for 2.4.9 against the requirements page.

Which high availability decisions change cost and operations

This table compares six architecture decisions for a self-hosted Magento Open Source store and shows how each one changes what your team must operate. Read each row for when the option fits, what it adds to failover, replication, cache and storage work, and what to confirm with your platform team before choosing. The main takeaway is that every extra node or shared component adds operational steps, so choose the simplest layout that meets your checkout uptime requirement.

Decision	When it fits	What it costs to operate	What to confirm with the platform team
Shared or dedicated Redis or Valkey for sessions and cache	A shared instance suits a single store with modest traffic. Dedicated instances fit stores where cache eviction or session loss would disrupt checkout during peaks.	Shared instances create a single point of failure and mix cache and session workloads. Dedicated instances add monitoring, memory sizing and failover configuration for each service.	Whether sessions and cache use separate instances or databases, the failover method for each, and how memory eviction policies are set for sessions.
Single primary database or primary with replicas and read routing	A single primary fits smaller catalogs and lower order volume. Replicas fit stores where reporting, admin or read-heavy traffic competes with checkout writes.	Replicas need replication lag monitoring and a rule for which reads may tolerate lag. Failover runbooks must name the promotion steps, application configuration changes and checks for each replica.	How read routing is configured in env.php, which queries are pinned to the primary, the acceptable lag threshold and who approves a replica promotion.
Varnish in front of the load balancer or behind it	Varnish in front caches full pages for all web nodes from one tier. Varnish behind the load balancer gives each web node its own cache and fits layouts where node-level control matters.	Varnish in front means one cache tier to size and fail over. Behind the load balancer, each node holds its own cache, so purge requests must reach every node and cache hit rates can vary.	How cache purge requests reach every Varnish instance, the health check settings on the load balancer, and how cached blocks for carts and customer data are excluded.
Shared file system or synced media for multiple web nodes	A shared file system suits a small number of web nodes that write generated files, media and static content to one location. Synced media fits layouts where each node keeps a local copy.	Shared storage adds a dependency that must be backed up and monitored. Synced media needs a process to keep copies consistent, and failed syncs can cause broken images or stale static files.	Which directories must be shared (media, static view files, generated code), the sync method and its failure alerts, and how deployments write static content across nodes.
RabbitMQ on its own host or co-located	Co-location fits small deployments with low message volume. A dedicated host fits stores that depend on queues for ERP sync, order processing or asynchronous jobs.	A dedicated host adds an extra server, patching cycle and monitoring. Co-location means a web or database problem can also stop message processing, and queue backlogs need alerts.	The supported RabbitMQ version for your Magento release, the clustering or mirroring setup, the queue depth alerts and who restarts consumers after a failure.
Active-passive or active-active database layout	Active-passive fits most self-hosted stores that need a standby for failover. Active-active fits multi-region or very high write volume, and it requires careful handling of write conflicts.	Active-passive needs tested failover steps and a defined recovery point. Active-active requires conflict handling, replication monitoring and application logic that tolerates concurrent writes, which raises testing effort.	Whether Magento's database connection setup and any installed extensions support the chosen layout, the expected recovery time and recovery point, and how failover tests are scheduled.

Build order for a highly available Magento Open Source stack

This sequence moves a single-server Magento Open Source store to separated tiers with several web nodes, shared state, a tested cache invalidation path and a controlled runner for cron and indexers. Each step closes with a check, so the stack is proven one layer at a time before the next layer depends on it.

Freeze the release and service versions
Choose the 2.4.x release and patch level the store will run through its support window, then pin every service version against Adobe's system requirements for that release. For 2.4.9, the listed set includes PHP 8.5, MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30 on Linux x86-64. Adobe supports only the listed combinations, so confirm the Varnish version for your chosen release before the build starts. The step closes with a signed version manifest that the build pipeline reads from.
Build the shared data and search services
Provision the database, Redis or Valkey, OpenSearch and RabbitMQ as their own tiers, each in a private network segment reachable only from the application nodes. The platform team sets authentication, TLS where the service supports it, backup jobs and monitoring for each service before any Magento code is deployed. The check is a connectivity test from a temporary application host that reaches all four services, plus a restore test of one database backup into a scratch instance.
Move sessions and cache off local disk
Configure Magento to store sessions in Redis or Valkey and to use the shared cache backend, so no node holds state that another node needs. Set the same settings in the environment configuration for every node, and confirm that the file-based cache directories are no longer the active backend. The check is a logged-in test session that survives a restart of the node that created it, with the customer still signed in when the next request lands on a different node.
Share media and generated code
Place the media directory on shared storage that every web node mounts, or serve media from one object store through a common path. Generate static view files and dependency injection code in a single build step, then publish the same artifact to all nodes instead of letting each node compile its own copy. Ask your hosting or storage team to confirm the shared mount's latency and failover behavior in writing. The check is an image uploaded through the admin on one node that displays correctly on every other node within the same deploy.
Add web nodes behind the load balancer
Deploy two or more identical web nodes running the same artifact, each with nginx and PHP-FPM, and register them with the load balancer using health checks that call a lightweight status route. Set session affinity only if the earlier shared session test is not yet closed, and document the decision. The check is a load test that drops one web node from the pool during the run, confirming that checkout requests complete on the remaining nodes without a visible error page.
Place Varnish in front of the web tier
Install Varnish between the load balancer and the web nodes, using the configuration Adobe provides for self-managed installations, and set the backend list to the web pool. Confirm that cacheable pages are cached and that checkout, cart and customer pages are passed through uncached. Then test the invalidation path: change a product price in admin, and check that the purge reaches every Varnish instance. The step closes when a purge is visible on all nodes within the timing your team agreed in advance.
Enable database replication with a failover plan
Configure one or more replicas from the primary database, and route read-only reporting traffic to a replica only where Magento's configuration and your extensions allow it. Write down the maximum acceptable replication lag, the promotion steps for a failed primary, and who decides on promotion. Then rehearse a planned failover in a non-production environment and record the time to recover and the number of writes lost. The check is a replica that stays within the agreed lag limit under peak write load, and a documented failover run that the on-call team has repeated.
Move cron and indexers to one runner
Designate a single controlled host to run Magento cron, indexers and queue consumers, and disable scheduled jobs on every web node. Keep the runner's schedule, logs and alerting in your central tooling, and confirm that the consumers for the message queue run under a supervisor that restarts them on failure. The check is a catalog change that is indexed and visible on the storefront within the expected window, plus a test where the runner is stopped and an alert fires before any queue backlog becomes customer-facing.

How single node, multi node and containerized layouts differ

A single node runs the web server, PHP, and the supporting services on one host, or on a small set of hosts with no redundancy between them. It is the simplest layout to build, patch, and back up, and it suits development, staging, and low-traffic stores where a short outage is acceptable. Its limits are structural: one failed host takes the storefront and checkout down, and a traffic peak competes with the admin, cron jobs, and indexers for the same CPU and memory.

What to check on a single node:

Confirm that the host meets the PHP, database, OpenSearch, Redis or Valkey, RabbitMQ, and nginx versions listed for your release in Adobe's system requirements.
Decide how the Varnish full-page cache is placed on the host and how it is sized, since it competes for memory with other services.
Plan regular backups of the database and media files, and test a restore before go-live.
Keep cron, indexers, and message consumers under monitoring so a stalled job is visible.
Note that moving later to several nodes means revisiting session storage, shared media, and cache placement.

Before relying on this layout for a payment store, confirm the uptime and recovery expectations with the business owner, since this model carries no built-in redundancy.

What drives high availability effort on a Magento store

This table lists the factors that most change the work and cost of a highly available Magento Open Source setup, with a way to keep each one under control. Read each row as a question to answer about your own store before estimating effort. Adobe's upgrade guidance names customizations, extension count, third-party integrations and coding practices as upgrade effort drivers, and the same items tend to create high availability rework.

Driver	Why it changes effort	How to keep it down
Number of web nodes	Each added node multiplies session, cache, media and cron coordination, and every node must receive the same code and configuration.	Keep sessions in shared Redis or Valkey, store media on shared storage, and deploy code to all nodes from one artifact.
Catalog and order volume	Larger catalogs lengthen indexing and raise OpenSearch and database load, while order volume drives queue backlog and checkout contention at peak.	Confirm indexer modes and schedules early, size OpenSearch and database tiers from load tests, and separate peak traffic tests from normal tests.
Customizations that write to shared state	Custom code that writes to sessions, cache keys, quotes or files outside the shared tiers breaks when requests land on different nodes.	Limit custom cache keys, route shared writes through documented services, and review each custom module for node-local state before release.
Third-party integrations (ERP, payment, tax)	Integrations that call Magento through queues or cache-dependent endpoints can duplicate, delay or lose work when consumers restart or cache is flushed.	Document a queue consumer model with named consumers, retry rules and dead-letter handling, and agree cache invalidation rules with each integration owner.
Environment count	Staging that differs from production in node count, cache layout or queue setup hides failover and load problems until go-live.	Build staging with the same topology as production, even at smaller size, and keep it under the same configuration management.
PCI DSS scope changes	Moving payment paths, scripts or hosted fields between tiers or nodes can widen the assessed environment and add evidence work.	Record each payment path and its hosts in the scope inventory, and review scope again before any change to load balancing, caching or payment routing.
Team operating model	Without a named owner for patching, failover tests, queue monitoring and cache rules, high availability settings drift and incidents take longer to resolve.	Assign owners for each tier, schedule failover tests and patch windows, and confirm which duties sit with your team and which with a partner in the written scope.

Securing sessions, cache and admin access in a clustered store

Once a store runs several web nodes behind a load balancer, every shared service becomes an access path that an attacker can reach. The cards below cover the controls that only matter because the store is clustered, from private networking for Redis or Valkey and RabbitMQ to consistent Content Security Policy headers across nodes. Broader application hardening is covered in the security hardening topic.

Private networking for Redis or Valkey and RabbitMQ

Session and cache data in Redis or Valkey, and queue traffic in RabbitMQ, should only be reachable from the web and worker nodes that use them. Place both services on a private network segment with no route from the internet or the storefront DMZ, and enable authentication on every listener. Confirm the bind addresses, firewall rules and credentials against the versions your environment runs, since Adobe's 2.4.9 requirements list Redis or Valkey 9 and RabbitMQ 4.3.

Keeping Varnish purge endpoints off the public internet

Varnish is the full-page cache in front of the web nodes, and its purge and ban handling must not be callable by anonymous visitors. Restrict purge requests to the Magento nodes' private addresses, or to an internal management address, at the load balancer and in the Varnish configuration. Test from outside the network that purge requests are refused, and confirm that cache invalidation still works when a product or price changes.

Two-factor authentication on the admin and its load balancer path

With several nodes, the admin URL may be reachable through the load balancer, a separate admin hostname or a restricted IP range, and each path must enforce the same controls. Require two-factor authentication for every admin account, and decide whether admin traffic should be limited to an internal network or a VPN. Check that the load balancer does not bypass the application's login and session checks, and that session affinity does not weaken them.

Matching access controls on database replicas

Replicas hold a full copy of customer, order and payment-related records, so they need the same access controls as the primary. Apply the same network restrictions, account least privilege, encryption in transit and audit logging to each replica, and to any reporting or backup copies that read from it. Review which accounts can connect to replicas, because replicas are often granted looser access for reporting than the primary receives.

Managing env.php and deployment secrets across nodes

The env.php file holds database, cache, session and encryption settings, and each web node needs the same values. Store these secrets in a managed secret store or a protected deployment pipeline rather than in the code repository, and restrict who can read them on each node. Confirm that the encryption key is identical across nodes, and plan how it is rotated and recovered, since a mismatch can break stored data and sessions.

Content Security Policy headers on every node

Magento Open Source supports Content Security Policy headers from 2.3.5, and from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages. In a cluster, the header configuration must match on every web node and on Varnish responses, or the same page will behave differently depending on which node serves it. Test each node after deployment, and check payment pages with your payment provider's scripts before enabling restrict mode changes.

How to prove checkout survives a node failure

The proof that checkout survives a node failure is a set of scripted failure tests, each with a stated expected result, run in a staging environment that matches production topology. Each test names the component, the action, the observable outcome and the evidence captured. A passing run means the team saw the documented behavior happen, not that the architecture diagram looks correct. Start by agreeing the list of tests with the people who will be paged when something breaks, because those are the people who will judge whether the behavior is acceptable.

The first test fails one web node during a scripted checkout run. A scripted run should cover browsing, adding to cart, logging in or continuing as guest, entering shipping, selecting payment and placing an order. Confirm that the load balancer removes the failed node from rotation, that the shopper's session and cart persist when the next request lands on another node, and that Redis or Valkey holds session data so no node stores it locally. Record which requests failed during the switch and whether any shopper saw an error page. Confirm with your Magento configuration and your load balancer documentation how health checks mark a node as down, because that interval sets how long errors can last.

The second test purges a product through the admin and confirms that every web node and every Varnish instance serves the change. Check the product page, the category listing and the price on the cart page from several client paths, and confirm that cache invalidation reaches each Varnish instance rather than only the one that handled the admin request. Repeat the check after restarting one Varnish instance to confirm the cache state is handled as expected. The third test stops the primary database during a rehearsal and follows the documented failover. Record how the application reconnects, which connection settings change, and which writes were lost. Orders placed in the window before failover are the critical ones to reconcile against payment records.

The fourth and fifth tests cover cache and queues. Stop one Redis or Valkey node and confirm the storefront degrades in the way your runbook describes, for example slower sessions or forced logouts, rather than failing checkout outright. Drain the RabbitMQ consumers and confirm that order and ERP messages queue and resume in order once consumers return. Load testing completes the picture: run the checkout path at the expected peak order volume in staging, with the same nodes, database replicas, cache, search and queue layout as production. Save the scripts, configuration versions, raw metrics and the write-up of each run, so the next upgrade or infrastructure change can repeat the same tests and compare results.

What to monitor, back up and document after go-live

A high availability topology only holds if someone watches it, can restore it and knows how to change it safely. The cards below cover the signals to track, the backups that must be tested, the runbooks that keep failover predictable, and the retest that each patch cycle requires.

Health checks for each tier

Define a health check for every tier: load balancer pool members, web nodes, the database primary and replicas, OpenSearch, Redis or Valkey, RabbitMQ and the cron host. Each check should test the service the tier provides, not only whether the port answers. For web nodes, confirm that a storefront page and a checkout step return expected responses. Alerts should route to a named owner, and the load balancer should remove a node that fails its check.

Replica lag and disk headroom

Track replication lag on every database replica, since a lagging replica can serve stale catalog or order data during a failover. Watch disk growth on the database, OpenSearch data nodes and media storage, because a full volume stops writes and can halt checkout. Agree thresholds with your DBA and confirm the alerting path with your monitoring team before peak season.

Cache hit rates and purge errors

Monitor Varnish hit and miss ratios and the rate of purge requests that fail. A falling hit rate after a deployment often points to a configuration or cache-tag change, and failed purges can leave stale prices or stock on product pages. Confirm the Varnish version your release requires, since Adobe lists supported Varnish versions per Magento release line.

Session store memory and eviction

Watch memory use and eviction counts on the Redis or Valkey session store. If the store evicts keys under memory pressure, shoppers can lose carts or be logged out mid-checkout. Confirm the eviction policy and maximum memory with your platform team, and test what happens to sessions when the session node restarts or fails over.

Queue depth and consumer status

Track RabbitMQ queue depth and the status of each consumer process used for asynchronous work such as order and inventory messages. A growing backlog or a consumer that has stopped will delay downstream updates, and those delays often surface first in ERP or fulfillment reports. Alert on both stalled consumers and sustained queue growth.

Cron and indexer status

Confirm that cron runs on schedule on a single designated node, and that indexers finish without errors after catalog or price imports. Duplicate cron execution across web nodes is a common cause of conflicting jobs. Review indexer status after each release, because a broken index can show wrong prices or stock to shoppers while every server still reports healthy.

Backups with a tested restore

Back up the database, media directory and configuration, including environment settings and secrets management references, on separate schedules and retention periods. A backup counts only after a restore to a separate environment has been completed and the store has been verified. Record the time the restore took, since that figure sets your realistic recovery expectations.

Runbooks for failover, purge and node replacement

Write step-by-step runbooks for database failover, full-page cache purge, replacing a web node and rolling out a release. Each runbook should name the owner, the commands or console steps, the verification checks and the rollback path. Rehearse the failover and node replacement runbooks in a non-production environment before relying on them during an incident.

Retest the topology each patch cycle

Adobe recommends upgrading every patch cycle to stay secure and PCI compliant, so the topology will change more often than a one-time build suggests. Each patch cycle should repeat failover, cache purge, session persistence and checkout tests against the new versions. Check the Upgrade Compatibility Tool results and the supported service versions before scheduling the release window.

Questions teams ask before building high availability for Magento Open Source

How much does a high availability Magento Open Source build cost?

No price can be stated responsibly from the research available here, so the honest answer is that cost follows from a written scope. The main drivers are the number of web nodes, whether the database runs as a primary with replicas or as a managed cluster, how many environments you need (staging, performance testing, production), whether OpenSearch, Redis or Valkey and RabbitMQ run in separate tiers, and the hosting model you choose. Ask any provider, including DeployOpen, for a quote that separates one-time build work (architecture, configuration, load and failover testing, runbooks) from recurring costs (infrastructure, licenses for any managed services, patching, monitoring and support). DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does it take to build Magento Open Source high availability?

Duration depends on how much of the platform already exists and how many tiers you are separating. A team starting from a single server needs to split web, database, search, cache and queue services, add a load balancer, and prove that sessions and cache behave correctly across nodes. Before committing to a timeline, confirm the current architecture, the environment inventory, and whether a staging environment matches production closely enough to test failover. The internal team must typically provide access to cloud or data center accounts, network and DNS change approval, a named owner for the store and payment integrations, and time for business testing of checkout. Ask for the timeline as a phased plan in the written scope, with each milestone tied to a deliverable.

Can our team build Magento Open Source high availability without a partner?

Yes, a capable in-house team can build it, provided it has experience with Linux administration, nginx, PHP-FPM, database replication, Redis or Valkey, Varnish and load balancing. The hard parts are rarely the initial installation. They are session and cache consistency across nodes, cron and indexer placement so jobs do not run twice, correct handling of media and static files, and rehearsed failover. Check whether your team can test each failure case and document it. A partner can run that work as a fixed-scope engagement with written deliverables, or your team can keep ownership and use a partner for specific reviews. Either way, decide who owns the runbooks and who gets paged when a node fails.

Does Varnish work on a self-hosted Magento Open Source store?

Yes. Adobe documents Varnish as the full-page cache accelerator for self-managed installations, while cloud-hosted Adobe Commerce uses Fastly instead. In a high availability design, Varnish sits in front of the web nodes and must be configured to match the store's cache invalidation behavior, so that price, stock and content changes appear when expected. Confirm that the Varnish version you plan to run is listed in the system requirements for your Magento release, since the requirements differ between 2.4.x releases. Also confirm how Varnish will be deployed for redundancy, because a single Varnish instance can become the bottleneck or the single point of failure you were trying to remove.

Is Redis or Valkey required for sessions in a multi-node Magento Open Source store?

For a store running on more than one web node, sessions should not live on local disk of one server, so a shared session store is needed. Adobe's system requirements list Redis or Valkey as supported services, and the version must match the release you run. For 2.4.9, the listed version is Redis or Valkey 9, while 2.4.8-p5 lists Redis or Valkey 8.1. Confirm which service you will use, how it will be made redundant, and how cache and session data are separated, since mixing them can cause cache flushes to log customers out. Decide also whether the session store is placed in its own tier and how it is monitored.

How does checkout behave during a database failover?

Checkout depends on the database for orders, quotes, stock reservations and customer data, so any failover interrupts writes for a period. Shoppers in the middle of a payment can see errors or duplicate attempts, which is why the design must specify how a failover is detected, how the application reconnects, and how the payment provider's callbacks are handled after the switch. Test this on staging with realistic load, including a checkout in progress, and confirm with your payment provider how pending transactions are reconciled. Do not promise uninterrupted checkout to the business until those tests have run, because the outcome depends on your replication mode, connection handling and integration design.

How does a high availability design affect PCI DSS scope and upgrades?

Adding nodes, a load balancer, a session store and replicas adds systems that may store, process or transmit cardholder data or that can affect the security of those systems, so each one must be assessed for scope. Keeping payment pages on a hosted payment solution reduces the cardholder data environment, but the infrastructure, administration paths and logging still need to be documented. For upgrades, every additional tier adds a version to track, and Adobe recommends upgrading every patch cycle to stay secure and PCI compliant. Ask for the architecture diagram, the list of in-scope components, and an upgrade procedure that covers rolling updates across nodes. Independent assessors, not DeployOpen, issue any PCI DSS report.

Which environment facts should we confirm before asking for a quote?

Gather the current Magento release and its end of support date, the PHP, database, OpenSearch, Redis or Valkey, RabbitMQ and nginx versions in use, the hosting model, expected peak traffic from your own analytics, the number and type of third-party extensions, and the ERP and payment integrations. Confirm where media and static files are stored, how cron and indexers run today, and what backup and recovery targets the business has set. Note also the availability target and whether it has been agreed in writing, because the design decisions follow from it. A written scope built on these facts lets you compare quotes on equal terms.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Magento Open Source high availability. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Map each tier (web, database, search, cache, queue, sessions) to its current host and version before proposing a layout
Confirm the supported combinations for your target 2.4.x release, including PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey and nginx
Agree in writing whether Varnish, session storage, replication and load balancing are in or out of the fixed scope

How we build

Stand up separate web, database, search, cache and queue nodes in your own cloud accounts or data centers
Configure Varnish full-page caching and Redis or Valkey sessions, then test cache hit behavior on cart and checkout paths
Run failover tests on web nodes and database replicas, recording what happens to in-flight checkouts

How we hand over

Deliver architecture diagrams, configuration records and runbooks for scaling, failover and cache purges
Document the load balancer health checks, session settings and replication monitoring your team needs to operate the setup
Walk your engineers through a failover drill so the runbooks are tested by the people who will use them

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover
Plan patch cycles and version moves against Adobe's published support dates, so the high availability layout is retested after each change
Review the high availability setup whenever PHP, search, cache or queue versions change, and before peak trading periods