Even in personal projects, designing the system with high traffic in mind becomes extremely valuable later. This article summarizes how backend developers should understand and utilize DB Connection Pools and Redis Caching.
1. Why Do We Need a DB Connection Pool?
Opening a new DB connection is actually very expensive.
- Network handshake
- Authentication
- Socket creation
If every API request opens and closes its own connection:
- Response time increases
- The DB becomes the bottleneck as soon as concurrent traffic spikes
1-1. How the Connection Pool Works
Connection Pool
- The server pre-creates multiple DB connections at startup.
- When an API request comes in → it “borrows” one connection.
- After the DB operation finishes → the connection is returned to the pool instead of being closed.
Spring Boot uses HikariCP by default.
spring:
datasource:
hikari:
maximum-pool-size: 20
minimum-idle: 5
connection-timeout: 30000
max-lifetime: 1800000
2. Concurrent Requests = Required Connections
2-1. One Request Uses One Connection
- It doesn’t matter whether you use MyBatis / JPA / JDBC
- A connection is required the moment a query is executed
- Even if multiple queries run inside a transaction, it still uses just a single connection
For example:
- 100 users call the “post list” API at the same time
- → 100 threads → 100 DB connections required
2-2. What If the Connection Pool Is Too Small?
If maximum-pool-size=10 and 100 users query simultaneously:
- 10 users get processed
- 90 users wait
- If the wait time exceeds the timeout → 500 error is thrown
3. Slow Queries Occupy Connections for a Long Time
For example, if a SELECT query takes 7–8 seconds:
- The connection is occupied for the entire 7–8 seconds
- Multiple slow queries can completely block the pool
- New requests fail to obtain a connection and eventually time out
In short, just a few slow queries can freeze your entire API.
4. Scaling API Servers Alone Does Not Solve the Problem
Many beginners think: “If traffic increases, just add more servers.” In reality, the DB hits its limit long before the API layer.
- API servers can easily scale via Auto Scaling
- But the DB is where all requests ultimately converge
- More API servers → more total DB connections → higher DB load
Example:
- 5 API servers × pool size 20 = 100 DB connections
- MySQL default max_connections = 151
- → A small surge can cause the DB to crash first
5. This Is Why Redis Becomes Essential
5-1. Redis Acts as a “Shield” That Protects the DB
Redis = In-memory caching server
- Caches frequently-read but rarely-changing data
- Provides 10–100× faster access than a DB
- No disk IO → no traditional bottlenecks
Examples of data ideal for Redis caching:
- User profile
- Post list
- Schedule list
- Announcements
- Configuration values
5-2. Redis Has Load Too — Just Far Less Than DB
- Can handle tens of thousands of requests per second
- CPU spikes can occur when TTL expirations cluster or when large values are stored
- But compared to relational DBs, Redis load is extremely light
6. Why Redis Is Valuable Even in Personal Projects
Even if traffic is low, adding Redis to a personal project helps you:
- Gain real-world experience with scalable architecture
- Learn practical topics like caching, TTL, invalidation, distributed locks
- Write strong, convincing experience in your resume
Examples of what you can implement:
- Cache post lists
- Cache comment counts
- Cache basic user information
- Invalidate cache when data is updated
- Tune HikariCP pool settings
7. Summary
- A DB connection pool improves performance and stability by reusing connections.
- Each request uses one connection; with enough concurrency, the pool is easily exhausted.
- Slow queries block connections and can freeze the entire system.
- Scaling API servers alone cannot solve DB bottlenecks.
- Redis absorbs read-heavy workloads and protects the DB.
- Even personal projects benefit greatly from Redis, both technically and in resume value.
Moving beyond simply “writing APIs,” this knowledge is essential for growing into a backend engineer who understands scalability and high-traffic systems.