The Real Cost of E-Commerce Downtime: A Conversation with Semyon Slepov on API Reliability and Small Business Outcomes

The global e-commerce market reached an estimated $6.42 trillion in 2025 and is on track for $7.41 trillion in 2026, a volume of spend that runs almost entirely through a thin layer of public-facing APIs. More than half of US businesses with fewer than ten employees now sell online, which means the people most exposed when those APIs falter are not the platform operators. They are small merchants whose entire revenue depends on someone else's service-level attainment. The gap between 99.9% and 98% reliability that looks like a rounding error on a status page reads as missing rent on a seller's monthly statement, and the question of how that gap actually gets held is less discussed than it should be.

Semyon Slepov is a Site Reliability Engineer with 15 years of experience building reliability into systems across online banking, e-learning, and major public-facing internet services used by billions of users. His current work focuses on large-scale data stores that power widely used consumer platforms, but the through line across his career has been the same one: when reliability slips, the people who absorb the cost are rarely the people running the dashboards.

We spoke with Semyon about a project that brought that pattern into clear view, rebuilding the reliability of a public-facing commerce API whose memory-related degradation was quietly costing small merchants on the other side.

What does the reliability conversation usually miss when you frame it from the small-business seller's vantage point?

Most uptime conversations get framed in operator language: five nines, SLA attainment, blast radius. That framing is useful for the people running the platform, but it hides the economic incidence. The cost of unreliability does not fall on the team that built the API. It falls on the people who depend on that API to make a living. When a marketplace API is sitting at 98% success rate, the platform is technically meeting most definitions of operational. For a small seller doing a few thousand transactions a month, 2% of failed requests is a meaningful share of their monthly revenue.

A measurable fraction of visitors never come back after a failure event. Permanent abandonment from a single outage can run as high as 9% of visitors, and that erosion is compounded by reduced repeat-purchase rates in the weeks that follow. The platform operator sees a transient dip in a graph. The merchant sees customers who quietly stop coming back. The two views are about the same event, but they tell very different stories, and the story that matters most to the people the platform was built to serve almost never makes it into the engineering review.

Where did this pattern come into clearest focus for you, and what was the system you were working on?

The project I will describe was a public-facing e-commerce API serving small merchants on a large consumer platform. When I started looking at it, the request success rate had been sitting around 98% for an extended period, well below the platform's stated target of 99.9%. The user-facing symptoms were a mix of intermittent errors, slow responses, and cart-checkout flows that would silently break. Internally, the service was experiencing recurring out-of-memory issues that were degrading the customer experience in ways that did not always trigger sharp alerts.

The reason this kind of problem persists is that it does not look catastrophic from the platform side. Dashboards show the service as up. Standard alerts do not fire. But the people on the other end, the sellers depending on that API to display their products, complete their checkouts, and process their orders, were absorbing the failure directly. My job was to figure out why the success rate was stuck below target, propose a fix that addressed the root cause rather than the symptom, and work with the software engineering team to put it into production.

What does a sub-99% success rate actually look like for the merchants on the other end, given how easy it is to miss from the platform side?

"Below SLA" is one of those phrases that obscures a lot of variation. A two-percentage-point gap between 98% and 99.9% sounds like a small adjustment in engineering terms. From the merchant's side, it is the difference between predictable revenue and a recurring tax on every batch of orders. A single significant outage event can drive cart abandonment rates up by 15% and repeat-purchase rates down by 23% in the weeks that follow, and those numbers fall to small sellers first, because their cushion for absorbing customer attrition is thinnest.

What makes this category of failure dangerous is that nothing looks like it is on fire. The service is up. The dashboards are green. The platform team does not have a crisis on their hands. The cumulative customer experience is degrading in a way that takes weeks to show up in higher-level business metrics. By the time someone notices the gross merchandise volume slipping, the failure has been running for long enough that the root cause is buried under months of unrelated changes. Detecting these issues earlier requires looking at the service through the customer's eyes, not just through the platform's instrumentation.

Memory-related degradation in a public-facing API is one of the slipperier failure modes, so how did you actually find the root cause and prove it?

The investigation started with the basics. I used the standard observability tools to confirm what the dashboards were showing: SLA consistently below target, and a memory profile that climbed too fast under realistic load. From there, I moved to the proprietary debugging tools to look at what was actually retained in memory, which call paths were generating the worst pressure, and where the garbage collection cycles were getting in the way of request handling. That gave me a hypothesis about which part of the service logic was responsible. Memory issues are particularly hard to chase because they often build up silently rather than crashing the service outright; estimates put memory leaks behind roughly 23% of production outages in modern containerized applications.

I then ran targeted experiments. Small modifications to the service code, applied to a controlled subset of traffic, with the results documented in a detailed report. That document became the basis for a working conversation with the software engineering team that owned the code path. The final mitigation refined how the API handled cached results before returning them, removing an invalidation step that was contributing to memory pressure without measurably improving the response. After the change went out, the API's success rate moved from around 98% past the three-nines target, and the gross merchandise volume of the product climbed by almost 5%. That last number sounds small as a percentage. For the merchants on the other side, it was the difference between losing customers every week and not.

Diagnosis usually lives with SRE while repair lives with software engineering. What makes that cross-functional work succeed when it succeeds?

Memory-related degradation rarely lives entirely in one team's ownership. The SRE side has the running system, the runtime telemetry, and the visibility into where pressure is building. The software engineering side has the code, the design intent, and the institutional memory of why a particular caching strategy or invalidation pattern got written the way it did. Diagnosis lives in one place. Repair lives in the other. If those two sides are not collaborating well, the problem can sit for months while each team waits for the other to act.

The thing that makes cross-functional debugging work is shared evidence. Not a hand-off, not a ticket with vague language about investigating memory issues. A detailed investigation report that lays out what was observed, which hypotheses were tested, what the experimental results were, and what mitigation options exist. When you give software engineers that level of evidence, the conversation moves quickly. They can confirm or push back on the hypothesis using their knowledge of the code, and you converge on a fix together. When you do not have that evidence, both sides end up debating opinions, and the problem stays unsolved.

After fifteen years of reliability work across online banking, e-learning, and major consumer internet services, what is the common pattern in how reliability gets undervalued?

The industries I have worked in look very different from the outside. Online banking is heavily regulated, with reliability tied to legal exposure. E-learning is brand-driven, with reliability tied to customer experience and renewal rates. Large consumer internet services are scale-driven, with reliability tied to advertising revenue and merchant economics. The pattern that shows up in all three is that the cost of bad reliability is paid by people downstream of the engineering team. Customers in banking get blocked from accessing accounts. Students and tutors in e-learning get interrupted sessions. Merchants on commerce platforms see their gross merchandise volume slip.

What that means in practice is that reliability investment is almost always under-prioritized until something forces the conversation. A regulatory finding, a customer escalation, sometimes a public outage. The work of an SRE is partly to push those conversations earlier, before the forcing function arrives. You make the cost of unreliability visible in terms the business can act on, not in terms only engineers understand. You translate "the request success rate is at 98%" into "we are losing about this much volume per month, and these are the sellers affected." That translation is half the job. The other half is fixing the actual problem.

What is the next real problem in this space as AI-driven traffic and richer data flows hit public-facing APIs, and what are you focused on?

The next chapter for this work is going to be defined by two pressures. The first is volume. As AI-driven traffic patterns and richer data flows move through public-facing APIs, the absolute failure surface grows. Even with the same reliability percentages, the count of failed requests scales with the count of total requests, and the economic exposure scales with it. The second is detection. Memory-related and pattern-driven degradation is going to be harder to spot in environments where AI agents are generating non-uniform load, and the cross-team workflows that work today are going to need to evolve to keep up.

What I am focused on is keeping the engineering discipline aligned with the people who absorb the cost when reliability breaks. That means investing in observability that surfaces customer-facing impact, not just internal health metrics. It means building investigation and collaboration workflows that move quickly when a symptom shows up, before it has time to compound. And it means continuing to translate reliability work into outcomes that the people downstream of the platform can actually feel. If those translations get easier and faster, the next decade of platform work will go better than the last one.