1
La justesse passe avant la vitesse.
Une vente en trop vous écarte du podium, même avec la meilleure latence.
01 · Le défi
Une billetterie qui ne vend jamais deux fois le dernier billet.
Vous construisez le back-end d'une billetterie qui tient le jour où tout le monde veut le dernier billet : aucun billet vendu deux fois, aucun paiement débité deux fois, et un service qui se relève après une panne.
VOUS LIVREZ
Une API HTTP conforme au contrat
Un dépôt GitHub qui démarre en une commande
Les fichiers déclaratifs obligatoires
21 jours
chrono
chrono
Trois règles d'or. Aucune exception.
Podium
perdu
perdu
2
La vérité vit dans un stockage durable.
Un stock tenu seulement en mémoire est perdu au redémarrage.
3
Le contrat est la loi.
Chemins, champs, codes HTTP et codes d'erreur. Une variante, même meilleure, est comptée comme une erreur.
openapi
.yaml
.yaml
La vie d'une commande, sous la charge.
Le premier arrivé est le premier à obtenir une réservation, dans l'ordre de validation en base. Ni l'arrivée réseau ni le paiement ne comptent.
held
converted
pending_payment
paid
10 min
Durée d'une réservation. Le checkout ne la prolonge pas.
1 à 4
Billets par réservation, montant toujours calculé par le serveur.
24 h
Même Idempotency-Key et même corps = même réponse.
Tout ou rien
Une commande est honorée entièrement ou remboursée entièrement.
Votre stack. Notre budget.
Langage, framework et base de données : libres. Seule contrainte, tout tient dans 2 vCPU et 4 Go de RAM au total. Les paiements passent par KrakenPay, le faux prestataire fourni en image Docker. Vous ne le modifiez pas.
2 vCPU4 Go de RAMPort 8080Réseau coupé
$ docker compose up --build api listening on :8080 krakenpay listening on :4010 $ curl localhost:8080/health {"status":"ok"}