Blog / DESIGN / Design system : pourquoi
DESIGN

Design system : pourquoi on démarre systématiquement par les tokens

Nadège Mballa· Tech Lead
05 août6 min de lecture
Schéma d'architecture Kolopay

Couleurs, typo, espacement — la fondation qui évite de tout refaire six mois plus tard.

Ce n’est pas un tutoriel — c’est un retour d’expérience. Chaque décision est datée, chaque bénéfice mesuré, chaque regret assumé.

1. La lecture avant l’écriture

Notre première optimisation n’a pas été de scaler l’écriture, mais la lecture. 80% du trafic était en read — dashboards, historiques, vérifications de solde. On a introduit une réplique read-only + Redis pour cacher les vues les plus consultées.

// résultat semaine +2
latence p50 210ms → 45ms
load db primaire 78% → 34%
cache hit ratio 89%
« Le bon réflexe c’est de tout scaler tout de suite. Le meilleur, c’est d’observer d’abord — puis d’agir là où ça compte. »

2. Découpage progressif du monolithe

On n’est pas passé aux microservices d’un coup. On a extrait 3 services critiques dans cet ordre — chacun avec sa DB, ses métriques, son SLO :

Le reste (settings, admin, reporting) est resté dans le monolithe. Il tourne toujours en prod aujourd’hui.

Nadège Mballa
Tech Lead chez EBIA TECH · 9 ans d’XP · Ex-Orange Labs
@nadegeMgithub/nmballalinkedin
LIRE AUSSI
Postgres tuning : les 6 réglages qui ont sauvé notre p99
ENGINEERING
Postgres tuning : les 6 réglages qui ont sauvé notre p99
Etok ERP : sync temps réel entre 34 magasins
CASE STUDY
Etok ERP : sync temps réel entre 34 magasins
Passer de Node à Go sur nos APIs : le vrai bilan
ENGINEERING
Passer de Node à Go sur nos APIs : le vrai bilan
© 2026 EBIA TECH CORPORATION · Douala, Cameroun