Accommodation Marketplace: Two Sides of a Transaction That Never Meet

Every marketplace starts as one product — a place to find a room — and becomes two the moment a stranger can list a room. The demand side and the supply side want opposite things, they are judged on different metrics, and most of the engineering is in the gap between them.

The scale

  a mid-sized accommodation marketplace
    1.2M listings
      - 400k hotels (contracted inventory)
      - 800k homes and apartments
        (individual hosts)
    8M guests per year
    2.5M bookings per month
    190,000 hosts, of which
      60% book less than once a month

    the asymmetry that defines it
      demand:    millions of users,
                 each with a few sessions
      supply:    a long tail of individuals
                 for whom a single bad
                 experience is the whole
                 relationship

That asymmetry is the design constraint. A demand-side outage loses sessions; a supply-side outage loses hosts, permanently, because the top 5% of hosts generate most of the inventory and they have options. A marketplace that grows demand while providers quietly disengage is a marketplace with a countdown.

Supply: onboarding, and where it actually fails

  listing a property
    1. the host describes it
    2. photos are uploaded
    3. the platform verifies identity,
       address, and (where required)
       the right to rent
    4. amenities are claimed
    5. the calendar is connected
       (an ICS feed, a channel manager,
        or manual blocks)
    6. the listing goes live

  where the real work is
    - photo quality and coverage
      (guests bounce on 3 photos of a
       dark room; this is the single
       biggest conversion lever)
    - amenity accuracy
      (a missing air conditioning or a
       mis-described bed size is a
       cancellation and a one-star)
    - calendar reliability
      (a host who double-books because
       two channels were not synced)

The calendar synchronisation problem deserves more attention than it gets, because it is where marketplaces lose money and hosts. A host connected to three channels with a two-way sync has a distributed consistency problem with a non-technical user at the end of it, and the failure mode is a double booking. The correct architecture is clear and the implementation is fiddly: a single source of truth per listing, a single writer per night, and channels that are readers except through an explicit, arbitrated write path. Conflict resolution is not “last write wins” because a stale channel feed will happily overwrite a real booking and sell the night twice.

The marketplace-level response is layered on top: an availability calendar per listing per night, a booking that atomically claims the night, a channel sync that is throttled and reconciled periodically rather than trusted continuously, and an overbooking policy with an explicit cost of walking a guest. Plus a cancellation penalty scaled to who caused it, because the asymmetry of consequences is what makes hosts behave.

Supply quality as a ranking problem

  a host with:
    - 40% response rate to enquiries
    - 2.4% cancellation rate (market
      average is 3%)
    - 4.6 average review score
    - 12 listings, all photographed in
      2019

  how should this rank against a
  professional operator's listing?

  the platform's incentive problem
    demoting a host visibly generates
    support contacts and churn
    hiding the demotion generates guest
    complaints

  the workable answer
    - quality signals feed ranking,
      not a visible badge
    - the visible signals are the ones
      the guest can verify themselves
      (reviews, response time, superhost
       status with published criteria)
    - the hidden signals are behavioural
      (cancellation, response, claim rate)
    - and there is a remediation path,
      not just a penalty

This is the central design decision in a two-sided marketplace: which quality signals are visible and which are implicit. Reviews, photos, and amenities are visible because the guest can judge them. Cancellation behaviour, response latency, and dispute history are behavioural signals the guest cannot verify, and surfacing them raw is both legally fraught and useless to a user making a decision. So they go into ranking, and the visible quality badges are defined by published criteria that the platform can stand behind.

The remediation path is what keeps this from being punitive. A host with a low response rate is usually a host with a broken notification setup or an unstaffed calendar, and a platform that silently demotes them will lose them, while a platform that tells them “your response time is below the top 10%, here is how to fix it” retains them. Metrics: guest-side outcomes (cancellation, complaint, review) segmented by host-quality decile, and supply-side retention by the same decile. If high quality correlates with host churn, the ranking model is punishing the wrong people.

Ranking that serves both sides

  demand-side ranking wants
    - predicted booking probability
    - price competitiveness
    - quality (reviews, photos, amenities)
    - relevance (location, amenities for
      the party, distance from centre)

  supply-side wants
    - impressions in the right market
    - fair exposure against competitors
    - a ranking they can act on
      (improve photos, add amenity)
    - not to be flooded with bookings
      they cannot service

  the conflict
    maximising short-term booking
    probability concentrates demand on
    already-strong listings
    -> new hosts get no impressions
    -> they get no reviews
    -> they stay weak
    -> the marketplace's supply
       quality degrades over time

The standard resolution is an explicit exploration and new-supply budget: a fraction of impressions reserved for listings below a quality or popularity threshold, subject to a relevance floor so it is not random. Add supply-side guardrails — per-host impression caps, a “you are receiving more enquiries than you can service” signal, and pacing so a host is not sent 40 enquiries in an hour on a property they manage alone.

Relevance floors are the part that makes exploration defensible. Showing a brand-new listing in a city the guest searched is exploration. Showing it to a guest who filtered for a specific neighbourhood and a specific amenity is not, and the conversion from that placement is low enough to be self-defeating. Exploration should be scoped to the constraints the guest actually stated and free within the rest.

Cancellation policy as a search dimension

  policy types
    - flexible: full refund until 24h
      before check-in
    - moderate: full refund until 5 days
      before, 50% until 24h
    - strict: 50% until 14 days, then
      non-refundable
    - non-refundable
    - some platforms: refund on
      legitimate cause (medical, family
      emergency) at host discretion

  why it is a search dimension
    a guest travelling for two weeks of
    work is indifferent to a 5-day
    policy; a guest booking a weekend
    around a birthday is not

  and it is a supply-side decision too
    a strict policy is how a host
    manages risk, and banning it
    removes supply for a legitimate
    reason

So the policy has to be filterable, visible in the result list, part of the booking terms, and immutable on the booking once made. The last part is the same lesson as hotel booking: snapshot the terms, do not evaluate them at cancellation time against whatever the current policy happens to be.

The legitimate-cause refund is the hard case and it needs a stated, evidenced process. “Contact us within 24 hours with documentation” is a process. “Contact us” is a promise you cannot keep. The operational cost is real — a flood of claims if the bar is too low, and a marketplace that ignores genuine hardship if it is too high — which is why it belongs in a documented policy with a human in the loop rather than in a fully automated flow.

Money: held, split, and sometimes clawed back

  the money flow
    guest pays
      -> platform holds (escrow-like)
      -> check-in happens
      -> funds release (minus commission)
         to the host
    or
      -> cancellation
      -> refund to guest per policy
      -> nothing to the host
    or
      -> dispute
      -> held while resolved

  why this is hard
    - "holds" are regulated differently in
      different jurisdictions; in several
      places holding customer funds
      without permission is a licensing
      problem
    - chargebacks are asymmetric in time
      (guest disputes in 120 days, host
      has already been paid)
    - a clawback from a paid host is a
      collection problem, not a
      transaction one

Payment collection is the area where a travel marketplace becomes a payments company, and the requirements are regulatory before they are technical. Money held between booking and check-in may need safeguarding, segregation, or a licence depending on the jurisdiction and the amount, and the tax treatment of the host’s income differs from the guest’s. Neither is solvable by engineering; both are solvable by knowing which jurisdictions you operate in and getting the structure reviewed.

The chargeback asymmetry is the operational risk that gets underestimated. A guest can dispute a charge weeks after the host has been paid and spent it, and the recovery path is a chargeback flow, a negative balance, or a collections process. The mitigations that actually work: strong evidence trails on every booking (the terms shown, the payment authorisation, the check-in record, the messages), a proactive refund policy that is generous enough to prevent disputes, and a reserve or rolling hold on host payouts that shrinks with the host’s history.

Disputes, and why they are a state machine

  booking states
    pending -> confirmed -> checked_in
                        -> checked_out
                        -> disputed
             -> cancelled
                -> refunded
                -> cancelled_paid_out

  a dispute is
    - raised by guest or host
    - bound by a FILING DEADLINE
      (typically 48-72h after check-in,
       or after check-out)
    - resolved with EVIDENCE:
      the listing as it was at booking
      (photos, description snapshot)
      the messages
      the check-in record
      the platform's own policy text at
      that moment
    - outcome: refund, partial refund,
      payout, no action

  the reason a snapshot is essential
    the host changes the listing
    description after the complaint
    -> without a snapshot, the
       "evidence" is whatever the page
       says now

The deadline is what makes this a system rather than a support queue. A dispute that can be opened indefinitely has no well-defined resolution and the platform accumulates unresolvable obligations. The filing deadline needs to be clear at booking time — “report issues within 48 hours of check-in” — and enforced, which means the platform has to send a check-in confirmation message that states the deadline, because a deadline the guest was never told about is not enforceable.

The evidence snapshot is the other non-negotiable. Listings change; hosts edit descriptions, remove photos, change amenities, and update policies after the fact. A dispute process that reads the current listing state is a process that can be gamed, and the snapshot is what makes the outcome the same regardless of when the dispute was filed.

Failure stories worth testing

Let a host’s calendar sync from a channel that also has a direct booking for the same night

Confirm the double booking is prevented by the single-writer-per-night rule. Last-write-wins will fail this.

Demote a high-cancellation host and watch supply retention

Compare to a host who receives a remediation message instead. Silent demotion should lose hosts.

Exhaust new-supply exploration and let the platform run for 6 months

Watch listing quality and host count. This is the supply-decay test and it is slow, which is why it is missed.

Set a strict policy for a host and confirm it does not remove them from supply

Confirm strict policies are filterable rather than banned.

Book a 2-week business trip with a 5-day policy and apply a leisure guest’s preferences

The policy should be filterable, not globally weighted by the wrong segment.

Let a host edit the listing description after a complaint is filed

Confirm the dispute reads the snapshot. Otherwise the evidence is whatever the page says now.

Open a dispute 3 weeks after check-in

Confirm the filing deadline rejects it and that the deadline was stated at booking and in the check-in message.

Process a chargeback 100 days after the host was paid

Confirm the reserve or rolling hold covers it, and that the evidence trail is complete enough to win.

Make the platform hold funds in a jurisdiction where that requires a licence

Confirm the compliance gate is enforced before launch in that market, not after.

Cap per-host impressions and compare booking distribution

Confirm the top hosts stop monopolising demand and that the tail’s conversion is still acceptable.

Send 40 simultaneous enquiries to a solo host in an hour

Confirm the pacing guard and the “capacity” signal fire. This is a supply-side churn driver.

Change a listing’s amenities after guests have booked

Confirm booked guests see the terms that were current at booking.

A production-ready architecture

   host onboarding
     - identity, address, right-to-rent
     - photo/amenity quality checks
     - calendar connection (ICS, channel
       manager, manual)
        |
        v
  +----------------------------------------------------------+
  |  LISTING + INVENTORY                                    |
  |  - single source of truth per listing                    |
  |  - single writer per night (arbitrated)                  |
  |  - channel sync as readers + reconciled writes            |
  |  - overbooking policy with a walk cost                   |
  |  - listing snapshot at booking time                      |
  +----------------------------+-----------------------------+
                               |
                               v
  +----------------------------------------------------------+
  |  SEARCH + RANKING                                        |
  |  - filters: dates, party, amenities, policy, price       |
  |  - ranking: quality signals, price, relevance           |
  |  - new-supply exploration budget with a relevance floor  |
  |  - per-host impression caps and pacing                   |
  +----------------------------+-----------------------------+
                               |
                               v
  +----------------------------------------------------------+
  |  BOOKING + POLICY SNAPSHOT                               |
  |  - atomic night claim, idempotent                        |
  |  - policy terms frozen onto the booking                  |
  |  - cancellation: refund ledger, cause attribution        |
  +----------------------------+-----------------------------+
                               |
                               v
  +----------------------------------------------------------+
  |  PAYMENTS (regulated flow)                               |
  |  - hold / release / clawback, jurisdictional gates       |
  |  - reserve or rolling hold against chargebacks           |
  |  - ledger entries, never a field                         |
  +----------------------------+-----------------------------+
                               |
                               v
  +----------------------------------------------------------+
  |  DISPUTES                                                 |
  |  - filing deadline, stated at booking + check-in message |
  |  - evidence: snapshot, messages, check-in record, policy |
  |  - outcome written to the ledger and both parties        |
  +----------------------------+-----------------------------+

  watch: double bookings, cancellation by cause, host retention
        by quality decile, dispute volume and outcomes,
        chargeback rate, new-listing survival

Delivery checklist:

1. Pick a single writer per listing-night and arbitrate channel writes explicitly. Last-write-wins over a channel feed produces double bookings and loses the best hosts you have.
2. Treat photos and amenity accuracy as the highest-leverage onboarding work, ahead of adding supply-side features.
3. Keep behavioural quality signals (cancellation, response, disputes) in ranking and out of the visible UI; publish the criteria behind the visible badges.
4. Give underperforming hosts a remediation path. Silent demotion costs you supply permanently.
5. Make cancellation policy a first-class filter and a first-class supply-side lever — strict policies are how hosts manage risk and banning them removes legitimate inventory.
6. Snapshot the listing and the policy at booking. Dispute outcomes must not depend on when the dispute was filed.
7. Implement a filing deadline, state it at booking, and restate it in the check-in message, because an unstated deadline is unenforceable.
8. Keep the money flow in a ledger with hold, release, and clawback semantics, and gate launches in new jurisdictions on the payments structure being reviewed.
9. Hold a reserve against chargebacks sized by host history; the asymmetry is the whole risk.
10. Budget impressions for new supply with a relevance floor, and pace per host so a solo host is not flooded.
11. Attribute cancellations to a cause and apply penalties scaled to who caused them.
12. Track supply metrics — retention by quality decile, new-listing survival — alongside demand metrics, because the two fail on different timescales.
13. Snapshot listing state for disputes including the platform’s own policy text as it was at that moment.
14. Make the check-in confirmation message carry the dispute deadline and the support path.

Common mistakes

Mistake	What actually happens	Better decision
Last-write-wins channel sync	Double bookings, best hosts leave	Single writer per night, arbitrated
Behavioural signals shown raw	Confusing, legally fraught, ignored	Hidden signals in ranking, visible badges with criteria
Silent demotion	Supply disengages permanently	Remediation path first
No exploration budget	New listings get no reviews, stay weak	Impressions budget with a relevance floor
No per-host pacing	Solo hosts are flooded and churn	Caps plus a capacity signal
Policies fixed globally	Removes supply or breaks segment fit	Policy as a filter and a supply lever
Dispute reads the current listing	Evidence can be edited after the fact	Snapshot at booking
No filing deadline	Unresolvable, unbounded obligations	Deadline, stated at booking and check-in
Funds held without review	Licensing problem in some jurisdictions	Jurisdictional compliance gates
No chargeback reserve	Host paid and clawed back	Reserve sized by history
Money as a field on the booking	Cannot express partial or repeated movements	Ledger entries
Only demand-side metrics	Supply decay is invisible until it is fatal	Retention by quality decile, listing survival
Onboarding as data entry	Low-quality listings flood the catalogue	Photo and amenity quality gates
Cancellation without cause attribution	No basis for fair penalties	Cause, with penalties scaled to it

The complete story in one minute

A marketplace is two products on one database, and they want opposite things: demand wants discovery, supply wants fair exposure and reliability. The asymmetry — millions of guests against a long tail of individual hosts for whom one bad experience is the whole relationship — is the design constraint. A demand-side outage loses sessions; a supply-side outage loses the top 5% of hosts permanently. So supply quality is not data entry and not a badge, it is a ranking input, and the key design decision is which signals are visible and which are implicit. Reviews, photos, and amenities are visible because a guest can judge them. Cancellation behaviour, response latency, and dispute history go into ranking, because surfacing them raw is useless to a user making a decision and legally fraught. And underperforming hosts get a remediation path, not a silent demotion — a platform that quietly demotes them loses them, while a platform that says “your response time is below the top 10%, here is how to fix it” retains them.

Supply decays slowly and is always missed. If ranking optimises short-term booking probability, demand concentrates on already-strong listings, new hosts get no impressions, get no reviews, and stay weak. The fix is an explicit exploration budget for new supply with a relevance floor, so it is never random, plus per-host impression caps and pacing so a solo host is not sent forty enquiries in an hour.

Cancellation policy is a search dimension and a supply-side lever simultaneously — a strict policy is how a host manages risk, and banning it removes legitimate inventory. Snapshot the terms onto the booking and filter on them. Disputes are a state machine with a filing deadline that must be stated at booking and in the check-in message, because an unstated deadline is unenforceable, and the evidence must come from a snapshot of the listing and the platform’s own policy text as they were — otherwise the outcome depends on when the complaint was filed. And the money is a regulated ledger: holds may need safeguarding or a licence depending on the jurisdiction, and chargebacks arrive weeks after the host has been paid, which is why the reserve scales with host history.

single writer per listing-night; listing snapshot at booking
behavioural signals in ranking, visible badges with published criteria
exploration budget with a relevance floor; per-host pacing
policy as filter and supply lever; dispute deadline stated twice
payments ledger with jurisdictional gates and a chargeback reserve

The hard part was never matching a guest to a room. It was running two businesses on one database, where the one that gets optimised quietly is the one that decides whether the marketplace still exists in two years.

What this team still owns

The marketplace owns the booking contract even when a host, channel manager, payment processor, identity provider, or insurer owns part of the workflow. That means a durable booking snapshot, one idempotency key per money-moving operation, a calendar-conflict queue with a named resolver, and reconciliation that can prove the booking, ledger, payout, and channel state agree. “The partner API accepted it” is an observation, not a reservation guarantee.

Technical references

• IETF RFC 5545: iCalendar
• OpenTravel Alliance: specifications
• Stripe: idempotent requests