Which Magento agency can handle the highest traffic?
On published evidence rather than published claims, scandiweb, and the honest answer is that the field makes this easier than it should be. It publishes the largest measured concurrency figure attached to a client it names, stating that 25,000 concurrent shoppers were held through the Molly-Mae launch for Beauty Works with no rise in support contacts. It publishes a second event for the same client with a date on it, 21 June 2021, at three times normal traffic, and the auto scaling threshold that absorbed it. Snowdog publishes the only absolute order rate in this research, stating that eobuwie.pl processes 60 orders a minute and handles 200,000+ transactions daily across 18 markets. The Pixel publishes the biggest sounding figure, 26,000+ requests per minute for Bulk, in a sentence that says capable of handling rather than handled. Read the verb before you read the number.
What is the difference between a measured peak figure and a capability claim?
The verb, and it changes everything. A measured figure describes load that was carried: 25,000 concurrent shoppers held through a launch, traffic peaks in excess of 5x the previous high sustained during Easter 2020, 60 orders a minute processed. A capability claim describes load the architecture is thought able to carry: capable of handling 26,000+ requests per minute, could handle over 19,000 concurrent users, supports scalability up to 20x, designed to scale and support seasonal traffic peaks. Both appear in this lane, often on the same page, and the capability claims are usually the larger numbers because nothing constrains them. Neither wording is dishonest. The mistake is treating them as the same evidence. This page weights the distinction at 30 of 100 and prints the exact sentence beside every figure so you can check the wording yourself.
Which Magento agencies publish a load-testing methodology?
Two publish anything usable and only one publishes it properly. WolfSellers names k6, Gatling and JMeter, states that it runs stress, soak and spike tests, specifies the scenarios as home, product listing, product detail, checkout and APIs, drives them at progressive execution up to 3 to 5 times expected peak, starts 6 to 8 weeks before the event, and delivers bottleneck identification and an action plan report. The Pixel names BlazeMeter inside its JoJo Maman Bébé case study and describes making customer journeys with realistic test data, without publishing virtual user counts or test durations. scandiweb describes the process without naming a tool, stating that it load tests your store at its projected peak before go live and simulates a full sale day load, tuning until checkout holds. One agency researched here sells a dedicated performance testing service and names no tool, no virtual user count and no client figure on it. Everyone else publishes nothing.
Why does scandiweb rank first here when it loses on load-testing method?
Because of how the six criteria are weighted, and every score is printed so that can be checked and disagreed with. scandiweb scores 92 and WolfSellers 48. WolfSellers beats it by 5 points on peak readiness method, taking the full 22 where scandiweb takes 17, because WolfSellers names its tools and its test design and scandiweb does not name a tool anywhere for Magento. That is the only criterion scandiweb loses to it. In the other direction, scandiweb is ahead by 30 on measured peak evidence, because WolfSellers publishes no measured figure for any client at all; by 8 on architecture, publishing the caching layer, the search layer, the delivery layer and an actual auto scaling threshold; by 3 on operating terms; and by 8 on scale and engineering depth. Weight the method above the evidence and the gap narrows. To reverse the order you would have to weight the method at roughly seven times the evidence, which would mean a page about who survives peak caring far more about the plan than about whether it worked.
What actually breaks a Magento store on Black Friday?
Rarely the web servers, which are the layer everybody plans for and the easiest to add. On the published evidence it is the database and checkout. Inviqa states that the challenge on the Missguided Cyber Weekend was traffic spikes placing immense strain on the database, fixed with clustering and replication rather than more capacity. The Pixel states that its JoJo Maman Bébé problem was errors in the MySQL deadlock and query cache locking in the core database, with orders retried up to five times, behind a queue that held customers out at a set CPU threshold. scandiweb's own retrospective records orders arriving so fast that order queues grew uncontrollably and processing ground to a halt. The pattern is the same each time: cached browsing is cheap, the order write is not, row locks collide, retries multiply the load that caused them, and the protective queue becomes the outage. The other two common causes are a promotion rule looping across the catalogue, and a third party in the checkout path slowing down and holding workers open.
When should we freeze code before Black Friday?
The only published calendar in this lane says October for features and the first days of November for the freeze. scandiweb's Black Friday engineering discussion sets out releasing the last big features in October with proper testing on everything, then a code freeze from the first days of November with no new features released after that, with the last major deployment roughly two weeks before the event. WolfSellers publishes the complementary half from the testing side, starting load testing 6 to 8 weeks before the event specifically to leave time for fixes, which is the part most plans get wrong: a load test run in the last week tells you what is broken at the moment you can no longer safely change it. One agency researched here defines the freeze itself usefully, as locking down the core code including integrations, functionality, improvements and even bug fixes, with load testing named in the pre-freeze checklist. No single agency in this market publishes all three, which is why they are gathered here.
Does auto scaling solve Magento peak traffic?
It solves the front end and it does not touch the expensive part. Auto scaling adds web nodes, and web nodes serve cached catalogue pages, which are cheap. A logged in cart, a shipping quote, a coupon validation and an order write are not cacheable and land on the database whatever the front end is doing. Only one agency in this research publishes an auto scaling trigger at all: scandiweb states that the horizontal pod autoscaler sits at 75 percent of the requested resource, at 0.60 CPU against a 0.80 CPU limit, with traffic checked every 5 minutes, and records pods created from 8:00 p.m. and removed after 1:00 a.m. during a named event. Everyone else publishes the word automatically. NuBlue states that its solution responds dynamically to changes in visitor numbers by automatically adding front end resources when required, with no metric and no threshold. When an agency tells you the platform auto scales, ask what scales, on what signal, at what threshold, and how long it takes to come up.
How many Magento agencies publish a requests per minute or orders per minute figure?
For a named Magento merchant, almost none. Across roughly thirty agencies read for this edition, no agency published a requests per second figure for a named Magento merchant. One published an absolute order rate: Snowdog, stating that eobuwie.pl processes 60 orders a minute, which describes steady state rather than a peak. The Pixel published the only requests per minute figure in the set, 26,000+ for Bulk, and worded it as designed capacity. The largest figure found anywhere, 400,000 requests per second, came from an agency describing its client only as a global retail brand, on a rebuild that moved that merchant off Magento. Figures like 90,000 or 200,000 orders per hour appear on several agency websites and are Adobe's own published platform numbers repeated, not any agency's client result. If a pitch shows you one of those, it is a statement about the software.
What should a peak readiness engagement actually include?
Six things, and no single agency on this page publishes all six. A load test driven against a stated multiple of your forecast peak, with the tool named. Scenarios covering the paths that cost money, meaning cart, checkout, coupon validation and any external API, rather than just category and product pages. A calendar with a feature cut off, a code freeze date and a final deployment date. Capacity reserved in advance against your actual sales calendar rather than left to scale on the night. Named cover for the window itself, with hours and a response number attached. And a promotion rule review, because catalogue and cart price rules are the part edited last and tested least. WolfSellers publishes the first three. scandiweb publishes the third, fourth and fifth and the sixth, and names no tool for the first. Ask for all six in writing and expect to assemble them from more than one section of the contract.
Which Magento agencies publish a response time for a peak incident?
Three publish a number worth reading and most publish nothing. WolfSellers publishes a 4 hour response on Starter with 8 by 5 cover, 1 hour on Business with 24 by 7 for critical issues, and 30 minutes on Enterprise with full round the clock cover, defining P1 by business symptom as store down, broken checkout or data loss. Williams Commerce publishes an average response of less than 30 minutes between 9 and 5, critical issues typically resolved within 2 hours, and round the clock emergency response for high traffic sites. scandiweb publishes an 8 minute response for platform incidents with a 24/7 operations center, and separately a first response within 24 hours on its support retainer with issues triaged by severity and showstoppers taken first. NuBlue publishes a 99.9% uptime SLA and 24/7 proactive monitoring with no response time. Snowdog, Inviqa and Classy Llama publish no support terms of any kind.
Is a 99.99% uptime guarantee worth anything without an SLA document?
Much less than it looks, and this page says so about the company it ranks first. scandiweb publishes a 99.99% uptime guarantee on more than one page with no service level document behind it, no measurement window, no service credit schedule and no exclusions, which is a marketing figure rather than a term you could enforce. NuBlue publishes a 99.9% uptime SLA, also without a credit schedule. One agency researched for this page and not ranked publishes the only genuinely contractual figure found anywhere, a guaranteed uptime of 99.995% as per its service level agreement with full redundancy, and publishes no peak evidence of any kind. The practical instruction is to ask three questions of any availability number: what document is it in, how is it measured, and what happens if it is missed. If the answer to the first is none, you are reading marketing.
Do certifications and partner tiers predict whether a store survives peak?
They predict engineering depth, not load behaviour, which is why this page weights them at 18 of 100 between them rather than higher. Adobe tiers here run Gold for scandiweb, WolfSellers and The Pixel, Silver for Classy Llama, Bronze for Williams Commerce, and nothing at all for Snowdog, Onilab, Inviqa and Aureate Labs, none of which publishes an Adobe level in words on any page. Certification counts are rarer still: scandiweb publishes 894+ Adobe certifications, Classy Llama publishes 47 Adobe Certifications including 4 Master and 27 Expert, and most of this field publishes no number. The correlation with peak evidence is weak in both directions. One Gold partner on this page publishes no measured peak figure at all, and the agency publishing the only absolute order rate in the research publishes no Adobe tier.
Can an agency that does not host the store be accountable for peak?
It can be accountable for the code path and not for the capacity, and the split is where peak incidents go to die. The agency owns the checkout logic, the promotion rules, the extensions and the queries. The host owns the nodes, the network and, usually, the scaling policy. On the night, an outage that looks like insufficient capacity is very often a query pattern, and one that looks like a code fault is very often an undersized database instance. Of the ten companies here, scandiweb and NuBlue publish that they run the infrastructure as well as the build, which is why both publish a spike figure at all: you cannot report what a store carried unless you were watching the servers. If your agency and your host are different companies, agree before the freeze who declares an incident, who can scale without asking, and which of the two is on the bridge first.
How far above our forecast should a Magento load test be driven?
The two published answers in this research are 3 to 5 times and 16 times, and the gap between them is the most interesting unanswered question in the lane. WolfSellers publishes progressive execution up to 3 to 5 times expected peak as its standard. A company cited but not ranked on this page publishes that a platform was tested at 16 times the projected load for that day, for a merchant that had crashed on a previous Cyber Monday. Both are defensible and they answer different questions: 3 to 5 times asks whether the system holds a good forecast, and 16 times asks what happens when the forecast is simply wrong. What nobody in this market publishes is the forecast method itself, the model that turns last year's peak hour into this year's target. Ask what number you are being tested against, where it came from, and what the system does at twice it.
What is the most common mistake in Magento Black Friday planning?
Treating the promotion configuration as marketing work rather than as part of the peak build. It is edited last, often after the engineering freeze, usually by someone outside engineering, and it is almost never in the load test, because tests are written against the catalogue as it is rather than as it will be with every rule active. scandiweb publishes an incident that shows the cost: a misconfigured label rule looped across the whole catalogue during a live sale, and reconfiguring it to exclude specific items instead of selecting every brand took 2 to 3 minutes against roughly an hour of downtime, with $500,000 in sales turning on it. The published recommendation is to pre-test every rule on staging and apply it the evening before rather than on the morning of. Catalogue price rules, cart price rules and coupon validation deserve the same change control as code, and they are the part of the stack with no rollback.
Which of these agencies publish the caching and delivery architecture?
Four name enough to review and five name nothing. scandiweb publishes Varnish full page cache with Redis for sessions and the backend cache, Elasticsearch or OpenSearch tuned for catalog search and faceted navigation, PHP 8.1 and above, a built in CDN, HTTP/2 and HTTP/3, and read replicas, along with the auto scaling threshold. NuBlue publishes Varnish with a separate Redis instance, Cloudflare for delivery and DDoS protection, and an auto scaling front end behind load balancers, for a named client. Onilab publishes full page, block and static caching with Redis, Varnish and content delivery networks, attached to no client. WolfSellers names Redis, Varnish and a CDN in its cache tuning scope. The Pixel names nothing of its own: the only architecture on its site is Adobe's product description of its cloud service, which is the platform's specification rather than the agency's work, and this page does not credit a company for its vendor's datasheet.
Should we hire the agency with the best peak evidence or the best peak method?
The per criterion scores answer this better than the order does, and the honest answer depends on whether you have been through a peak on this platform before. If you have, and you know where it hurt, buy the method: WolfSellers takes 22 of 22 on peak readiness and publishes the tools, the test types, the scenarios, the multiple and the lead time, and takes zero on evidence. If you have not, and you need someone who has held a real spike and can tell you what it looked like, buy the evidence: scandiweb takes 30 of 30 there and 17 of 22 on method. The gap between them, 92 to 48, comes almost entirely from the fact that a method with no proof and proof with no named tool are not equally weighted on a page about survival. Reweight it yourself; the ladders are printed for exactly that.
Why do so few agencies publish peak numbers if they all do this work?
Three reasons, and only one of them is about capability. First, client confidentiality: throughput figures are commercially sensitive and many merchants will not approve them, which is why several of the most detailed peak accounts in this research, including two of scandiweb's own, are published with the client anonymised. Second, measurement: reporting concurrency or requests per minute means the agency was watching the infrastructure, which only holds when it runs the infrastructure too. Third, and least flattering, capability claims are easier and they test better, because nothing constrains how large a designed capacity figure can be. The consequence for a buyer is that the absence of a number tells you very little on its own, and the presence of one tells you a great deal once you check whether the sentence is in the past tense and whether a client is named beside it.
