Maison Dlala: live auctions where the server is always right

Selling valuable objects remotely, live, to buyers who must trust every bid: the same price for everyone, the same clock, no bid counted twice — and auction houses running their own catalogues, lots and sales.

An entrepreneurial project (France / Algeria). Version 2 adds professional auction houses alongside members' listings: catalogued, timed and live sales, consignment, settlement between buyer, house, consignor and platform. Four languages: French, Arabic (right to left), English, Spanish.

• The server owns the truth: the browser never decides a price, a clock or a winner.
• Standalone MongoDB, no multi-document transactions: every guarantee must fit in one atomic write.
• Professional-sale payments blocked for real money until legal and provider checks are done — the interface must not imply otherwise.
• Full right-to-left Arabic, down to mirrored gallery arrows.

1. 01

   MongoDB decides

   A bid is accepted by one atomic conditional update; so is a close, which records the sale in the same write.

2. 02

   Redis carries

   The Socket.IO adapter relays emits between instances. Redis decides nothing, holds no lock, nothing financial depends on it.

3. 03

   Clients reconcile

   An event is a fast hint. Every state carries a version (`rev`): a late or duplicated event can never undo a newer state.

4. 04

   LiveKit for video

   Computer camera plus a phone as second camera; tokens minted per request, no socket event triggers a video operation.

Real-time architecture principle — the code repository stays private.

1. 01

   Idempotency inside the write that claims the price

   Every bid confirmation carries a client key. The key is recorded in the same atomic update as the price: a key can claim only once, on any instance. A retry gets the original receipt; reusing a key for another amount is refused (409), even under concurrency.

2. 02

   Bid privacy at the server boundary

   No bidder id, name, email or phone reaches a browser through a public payload. Bidders become “Bidder 004”: a per-sale rank, stable, not derived from the account id, with no secret to manage.

3. 03

   Plugging live sales into the existing money path

   Two options: a direct order model (rewrite ~20 consumers, every payment provider included) or an adapter that creates, for a live result, the sale record those consumers already expect. Chosen: the adapter — not because it is shorter, but because the alternative rewrote the money path.

4. 04

   Several instances, one truth

   The multi-instance audit found a per-process cache that went wrong after a bid on another instance (removed), an adapter attached after start-up that could fail silently (fixed), and a room join that accepted any name (fixed: a socket can no longer listen to another user's private events).

Every version passes automated suites before it is tagged: backend suites in multi-instance mode, UI suites per journey (live room, bidding, mobile, reconnection), dedicated simulations (sale authorisation, seller-as-viewer), then public checks after deployment and an axe accessibility audit on six pages in French and Arabic.

• v2.6.2 in production and showroom (November 2026): accounts, two-factor authentication, timed and live sales, consignment, role-based professional spaces, four languages.
• Bids that are idempotent, private and consistent across instances.

The product, for real

Lot photos: Wikimedia Commons, CC licences — full credits in the product.

• 01Put the guarantee in the write, not around it: a key stored afterwards protects nothing.
• 02The smallest safe design beats the cleanest one when it touches money.
• 03An honest “built, switched off” status beats a feature that only looks like it works.

• Live product
• Public guide, screenshots of the real pages in four languages
• Engineering contracts and reports (DL-2001 to DL-2004)Private repository — walked through in interviews