Hamed Cédric SYLLA

🪧 Introduction

Tu as déjà eu une API lente à cause de requêtes répétitives en base ?

👉 Exemple classique :

• Une méthode appelée 100 fois
• Qui fait toujours la même requête
• Avec toujours le même résultat

Résultat :
💥 surcharge inutile de la base
💥 latence qui explose
💥 scalabilité limitée

Et pourtant… Spring Boot propose un système de cache natif ultra simple à activer.

Dans cet article, on va voir :

• Pourquoi utiliser le cache
• Comment fonctionne le cache natif de Spring Boot
• Comment l’implémenter rapidement
• Les pièges à éviter
• Les limites (et pourquoi tu passeras peut-être à Redis plus tard)

1. ⚡ Pourquoi utiliser un cache ?

Le principe est simple :
👉 éviter de recalculer une donnée qui ne change pas
Sans cache :

Client → Service → DB → Résultat
Client → Service → DB → Résultat
Client → Service → DB → Résultat

Avec cache :

Client → Service → DB → Résultat (mis en cache)
Client → Service → Cache → Résultat
Client → Service → Cache → Résultat

🎯 Résultat

✔️ Moins d’appels à la base
✔️ Temps de réponse réduit
✔️ Meilleure scalabilité

2. 🧠 Spring Cache, c’est quoi ?

Spring propose une abstraction simple via :

@EnableCaching

Et des annotations :

• @Cacheable
• @CacheEvict
• @CachePut

💡 Important

Elle permet de brancher facilement différents systèmes de cache sans changer ton code métier.
Spring Boot fonctionne avec plusieurs providers de cache (EhCache, Caffeine, Redis…).
Ici, on utilise le comportement par défaut, mais on verra dans un prochain article comment brancher un cache distribué comme Redis.

Par défaut :
➡️ cache en mémoire basé sur une ConcurrentHashMap

3. 👨‍💻 Mise en place du cache

Étape 1 – Ajouter la dépendance dans pom.xml (maven)

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-cache</artifactId>
    </dependency>
</dependencies>

Étape 2 – Activer le cache

@SpringBootApplication
@EnableCaching
public class Application {
}

Étape 3 – Ajouter du cache sur une méthode

@Cacheable("users")
public User getUserById(Long id) {
simulateSlowService();
return userRepository.findById(id).orElseThrow();
}

👉 Ce qui se passe :

• 1er appel → DB + mise en cache
• Appels suivants → cache direct

🔍 Par défaut, la clé du cache

Spring utilise :
clé = paramètres de la méthode

Ici :
getUserById(1) → clé = 1

4. 🎯 Les annotations essentielles

🟢 @Cacheable

👉 Met en cache le résultat

@Cacheable("products")
public Product getProduct(Long id) { }

🔴 @CacheEvict

👉 Supprime une entrée du cache

@CacheEvict(value = "users", key = "#id")<br>public void deleteUser(Long id) { }

🟡 @CachePut

👉 Met à jour le cache sans passer par @Cacheable

@CachePut(value = "users", key = "#user.id")<br>public User updateUser(User user) { }

5. ⚠️ Les pièges classiques

1. Le cache ne fonctionne pas dans certains cas

👉 Cas très fréquent :

public void methodA() {
    methodB(); // ❌ cache ignoré
}

@Cacheable("data")
public String methodB() { }

💥 Pourquoi ?
➡️ Spring utilise des proxies
➡️ Les appels internes ne passent pas par le proxy

👉 Solution :

• appeler depuis un autre bean
• ou injecter le bean lui-même

2. Données jamais rafraîchies

👉 Si tu caches sans éviction : tu peux servir des données obsolètes

👉 Toujours réfléchir à :

• quand invalider ?
• quand mettre à jour ?

3. Mauvaise clé de cache

@Cacheable("users")
public User getUser(User user)

Mauvais si equals/hashCode mal définis

4. Cache sur des méthodes non pertinentes

Ne cache PAS :

• des données très dynamiques
• des appels uniques
• des résultats énormes

6. ❗️ Les limites du cache natif

1. Cache local uniquement
   • Chaque instance a son cache
   • Pas partagé entre plusieurs serveurs
2. Pas de TTL natif (simple)
   • Pas d’expiration automatique facile
3. Pas adapté aux architectures distribuées
   • Si tu passes en microservices → problème
4. Perte du cache au redémarrage

7. 🧠 Quand utiliser ce cache ?

✔️ Bon cas

• données rarement modifiées
• lecture fréquente
• application simple (mono-instance)

❌ Mauvais cas

• données critiques en temps réel
• multi-instance
• besoin de synchronisation

8. 🔥 Et après ?

Quand ton application grandit, tu vas vouloir :

• un cache partagé
• une expiration (TTL)
• de la scalabilité

C’est là que des solutions comme Redis entrent en jeu

9. 🛡️ Bonnes pratiques

✔️ Nommer clairement tes caches (users, products)
✔️ Toujours prévoir une stratégie d’invalidation
✔️ Ne pas cacher « par défaut » → réfléchir au besoin
✔️ Monitorer les performances

🧭 Conclusion

Le cache natif de Spring Boot est :

✔️ Ultra simple à mettre en place
✔️ Parfait pour démarrer
✔️ Très efficace pour booster les performances

Mais :

❗️ il montre vite ses limites en production avancée

C’est une excellente porte d’entrée avant de passer à des solutions plus robustes comme Redis.

📚 Sources & lectures recommandées

• Documentation officielle Spring Cache
• Spring Boot Caching Guide
• Cache Abstraction in Spring Framework