Discuss your engineering challenge
Industry

Marketplaces

A marketplace outage is not a lost session. It interrupts work in progress, on both sides of the market, at the same time — which makes reliability an existential property rather than a quality one.

Engineering context

What makes engineering for marketplaces different

These are the conditions that change the shape of the problem. They are why a generic approach underperforms in this sector.

Downtime has two costs, not one

A content platform loses sessions when it fails. A marketplace loses sessions and interrupts transactions already underway, while simultaneously signalling to sellers that the platform cannot be relied on. The supply side is the harder of the two to recover, because sellers who lose confidence in uptime move inventory elsewhere and do not necessarily return.

The load profile is spiky and partially external

Marketplace demand responds to events, promotions and seasonality that the platform does not control. Capacity planning has to accommodate peaks that are neither smooth nor entirely predictable, which changes the trade between provisioned capacity and elasticity.

Search visibility is a supply acquisition channel

Listings are discovered through search, which means crawl budget and indexation are directly connected to how many buyers see a seller's inventory. A discoverability fault on a marketplace is a product problem, not a marketing one.

Live remediation is the only option

A trading marketplace cannot be taken offline to be fixed. Every change during remediation has to be introduced into a live, revenue-generating system, which constrains both the technique and the pace of the work.

Typical problems

What usually goes wrong

Critical downtime with no clear cause

Failures at load where the reported symptom sits several tiers above the actual constraint, making the fix non-obvious from the point of failure.

Cannot distinguish a capacity ceiling from a defect

A platform that fails under load may be under-provisioned or may have a bug that only manifests at scale. The two require opposite responses, and adding hardware to a stability defect does not resolve it.

Listing discoverability limits supply value

Crawl-budget and indexation problems reducing how much inventory is discoverable, which reduces the value sellers get from listing.

Approach

How we work in this sector

The work is grouped by objective rather than by service, because in this sector the objectives interact.

Recover, then harden

  • Stabilisation as the first objective, accepting temporary inefficiency
  • Full serving-path diagnosis from connection layer to data tier
  • Constraint identification rather than symptom treatment

Remediate in place

  • Changes introduced without service interruption
  • Controlled rollout with rollback capability
  • Validation against production behaviour throughout

Make it durable

  • Infrastructure corrected for the observed load profile
  • Observability so the next constraint is visible before it saturates
  • Operating practice the client can sustain
Related work

Engagements in this sector

The reason this page exists rather than a generic one.

Marketplaces

Platform recovery

A large marketplace platform in the United States was experiencing critical downtime from compounding traffic and application faults. Soludome analysed requests through the web application firewall, identified and blocked the DDoS patterns, and repaired a third-party payment flow that allowed links to be generated repeatedly without authentication. Server load fell and platform performance improved after the work.

Around 2020initial recovery; occasional support since
Questions

Frequently asked

Can you help us if we are currently down?

Yes — recovery engagements are a normal starting point and we do not require a discovery phase before beginning work on a platform that is failing. The first objective is stabilisation; diagnosis and durable remediation follow once the platform is up.

How do you work on a system that cannot be taken offline?

Carefully, and with a stricter process than an offline project. Every change is introduced incrementally with rollback available, validated in production, and preceded by the least invasive evidence-gathering that can confirm the hypothesis. That makes live remediation slower than a rebuild and it is the only approach that does not interrupt revenue.

We are under an NDA. Can you still produce a case study?

Yes, when the client permits a useful account that cannot identify them. We keep the name and identifying details private and publish only the problem, work and outcome the agreement allows.

Read next

Related capabilities and work

CapabilityHigh-Traffic WebsitesCapabilityInfrastructure EngineeringCapabilityMarketplace SEO EngineeringCase studyMarketplace platform recoveryIndustryOnline communities

Tell us what your marketplaces platform is doing

The symptoms are usually more informative than the diagnosis. We will tell you what we think is happening.

Discuss your engineering challengeView our work