Pessimistic vs Optimistic Lock : la gestion de concurrence expliquée (avec de la pizza, Tinder et du code Laravel)

On essaie de faire plaisir à l'équipe produit en lui sortant des features plus vite qu'une glace ne fond au mois d'août, on gère les changements de cap de dernière minute, et on a toujours cette horrible impression d'essayer d'attraper le vent avec une épuisette.

Puis le drame arrive : une race condition en production à 2h du matin qui vient joyeusement pulvériser l'intégrité de vos données.

Gérer la concurrence en base de données sans tout faire crasher, c'est un peu comme négocier le dernier morceau de pizza lors d'une soirée de fin de projet : si tout le monde se jette dessus en même temps sans règles, c'est le chaos. Pour éviter le carnage, Laravel nous offre deux armes majeures : le Pessimistic Lock et l'Optimistic Lock.

Pour que ce soit limpide, faisons une petite analogie avec les applications de rencontre.

1. Le Pessimistic Lock : Le profil d'une femme sur une app de rencontre

La métaphore

Imagine une femme inscrite sur Tinder. Elle ouvre l'application et reçoit immédiatement environ 1 500 likes à la seconde. Si la plateforme laissait entrer toutes les requêtes en même temps sans verrouiller la ligne, le serveur exploserait en deux minutes chrono.

L'approche est pessimiste : « Je pars du principe que tout le monde va vouloir la liker en même temps, donc je verrouille tout tout de suite. »

En pratique avec Laravel

Dans Laravel, on gère ça proprement dans une transaction avec des méthodes dédiées :

• lockForUpdate() (Verrou exclusif) : Personne ne touche, ne lit, ni ne modifie la ligne tant que la transaction n'est pas bouclée. Le videur est en position.
• sharedLock() (Verrou partagé) : Idéal pour autoriser les autres à lire la donnée tout en interdisant formellement de la modifier tant que tu n'as pas fini.

use App\Models\Profile;
use Illuminate\Support\Facades\DB;

DB::transaction(function () {
    // Verrou exclusif en écriture
    $profile = Profile::where('id', 1)->lockForUpdate()->first();
    $profile->increment('match_count');

    // Ou version lecture sécurisée sans bloquer les autres en lecture :
    // $profile = Profile::where('id', 1)->sharedLock()->first();
});

• Quand l'utiliser ? Systèmes bancaires, gestion de stocks ultra-tendus, ou ventes flash. La sécurité absolue prime sur la performance pure.

2. L'Optimistic Lock : Le mec lambda sur Tinder (ou la méthode zen)

La métaphore

Passons maintenant au profil d'un mec lambda sur la même application. Les notifications se font rares, les interactions sont espacées, et le risque d'avoir deux personnes qui modifient le même profil au même millième de seconde tend vers zéro.

La philosophie est optimiste : « On reste zen, ça devrait bien se passer. Si un conflit survient au moment d'enregistrer, on avisera. » Pas besoin de poser des verrous lourds qui plombent les performances de la base de données.

En pratique avec Laravel

Laravel ne propose pas d'optimistic locking magique natif, mais un simple champ version fait parfaitement l'affaire :

use App\Models\Profile;

$profile = Profile::find(1);
$currentVersion = $profile->version;

// ... l'utilisateur modifie ses infos tranquillement ...

$updated = Profile::where('id', $profile->id)
    ->where('version', $currentVersion)
    ->update([
        'bio' => 'Développeur PHP un peu trop passionné',
        'version' => $currentVersion + 1,
    ]);

if (!$updated) {
    throw new \Exception("Oups ! Quelqu'un d'autre a modifié ce profil entre-temps.");
}

• Quand l'utiliser ? Applications SaaS, profils utilisateurs, CMS ou plateformes où les lectures explosent face aux écritures. Ça évite de bloquer bêtement la base pour rien.

En résumé pour votre archi

• Pessimistic (lockForUpdate / sharedLock) : Sécurité maximale, zéro risque de conflit, mais attention aux ralentissements et aux deadlocks si c'est mal ordonné.
• Optimistic (colonne version) : Performance et fluidité maximales, gestion applicative des conflits.

En tant que freelance, choisir la bonne stratégie de verrouillage, c'est l'assurance de ne pas passer ses week-ends à réparer des pots cassés en prod.

Besoin d'auditer vos architectures Laravel ou d'optimiser vos requêtes SQL ? [Parlons-en !]