Why we removed caching from a critical API

Source: Dev.to

Introduction

When we think about data caching in an API, we automatically imagine faster response times, fewer database calls, and overall better performance. The more critical the API (e.g., financial), the more benefits caching can bring. However, in one specific scenario, caching became a bottleneck.

Background

The API in question is an on‑premises REST endpoint built with Spring Boot and numerous integrations. It worked well in production, but to become more scalable, stable, and capable of running in high‑availability, multi‑instance mode, the team needed to reconsider its architecture.

Options Considered

• Distributed caching (e.g., Redis) – would add new components, maintenance overhead, and require additional skills.
• Synchronizing Spring cache between instances – error‑prone due to the classic cache‑invalidation problem.
• Removing caching altogether – ultimately chosen after extensive deliberation.

Reasons for Removing Caching

1. Cache synchronization complexity – custom mechanisms across instances are fragile.
2. Infrastructure cost – introducing Redis brings extra components and operational burden.
3. Write‑heavy workload – the API writes more data than it reads, so caching added unnecessary lookups.
4. Low read traffic – heart‑beat checks occur every 30 seconds; other read traffic is not significant.
5. Gradual traffic growth – volume is increasing slowly, not exponentially.
6. Upcoming cloud migration – a redesign is planned within the next 12 months, making a lightweight design preferable.
7. High‑availability requirement – must be achieved by design, not by accident.

Trade‑offs

The decision resulted in a modest performance hit in exchange for improved high‑availability, stability, and simplicity. Load testing confirmed that the impact on response time was acceptable.

Lessons Learned

• Best practices like caching must be evaluated for fit before being applied.
• Consider the deployment environment (on‑premises vs. cloud), data load, consumer size, non‑functional requirements, and long‑term impacts.
• Over‑engineering can introduce more problems than it solves.

Outcome

The API became leaner, could run in multiple instances without concerns about stale data, and met the high‑availability goals. The team now has a simpler, more maintainable service ready for future cloud migration.