DEV Community: Shubham Bhati

Spring Boot Security: Don't Expose That Sensitive Property

Shubham Bhati — Tue, 14 Jul 2026 05:53:48 +0000

Ever found yourself accidentally committing sensitive keys or passwords to your Git repo? It's a common slip-up. In Spring Boot, the easiest way to avoid this for things like API keys or database credentials is to keep them out of your main application.properties or application.yml.

Instead, use environment variables. Spring Boot automatically picks them up. For example, if you have a property app.external.api.key, you can set an environment variable named APP_EXTERNAL_API_KEY.

Your application.properties would still declare it:

app.external.api.key=${EXTERNAL_API_KEY:default_fallback_key}

This way, your code is clean, your repo is safe and you can manage your secrets per environment (dev staging prod) without touching the codebase.

Stop Holding DB Connections Hostage

Shubham Bhati — Mon, 13 Jul 2026 06:39:12 +0000

We often throw @Transactional on Spring Boot service methods without thinking. If your method queries PostgreSQL, calls an external API and updates Redis, you hold that HikariCP database connection for the entire API call duration. On cheap servers, this kills performance fast.

HikariCP defaults to 10 connections. If 10 users hit a slow external API, your app freezes. Keep transactions tight.

// Bad: Connection held during slow API call
@Transactional
public void checkout(OrderDto dto) {
    Order order = repo.findById(dto.id());
    paymentService.charge(order); // Slow
    order.setStatus(PAID);
    repo.save(order);
}

// Good: Connection held only for DB write
public void checkout(OrderDto dto) {
    Order order = repo.findById(dto.id());
    paymentService.charge(order);
    updateStatus(order.getId());
}

@Transactional
public void updateStatus(Long id) {
    repo.updateStatus(id, PAID);
}

Redis as a Spring Boot Session Store: Speed Up Your Apps

Shubham Bhati — Sun, 12 Jul 2026 06:18:46 +0000

You're building a Spring Boot app and notice session management is a bit sluggish. Why not offload that to Redis? It's incredibly fast and way cheaper than keeping it in-memory or on a relational DB. Here's the quick setup:

First, add the Spring Data Redis dependency:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

Then, configure your application.properties or application.yml:

spring.redis.host=localhost
spring.redis.port=6379

Now, enable RedisHttpSession in your main application class:

@SpringBootApplication
@EnableRedisHttpSession
public class YourAppApplication {
    // ...
}

That's it. Spring Boot will automatically use Redis for session storage. Your users will thank you for the snappier experience and you'll save on server resources.

Stop Letting HikariCP Kill Your Cheap VPS

Shubham Bhati — Sat, 11 Jul 2026 21:24:07 +0000

If you are running Spring Boot, PostgreSQL and Redis on a 512MB RAM VPS to keep costs under ₹100/month, the default HikariCP connection pool will crash your system. Spring Boot defaults to 10 connections. Add database memory overhead and your tiny server instantly runs out of memory.

For early-stage apps making money, you don't need 10 active connections. A pool size of 2 or 3 can easily handle dozens of concurrent users because database operations finish in milliseconds.

Limit your pool size in application.properties:

spring.datasource.hikari.maximum-pool-size=3
spring.datasource.hikari.minimum-idle=1
spring.datasource.hikari.idle-timeout=10000
spring.datasource.hikari.max-lifetime=30000

This simple change keeps your memory footprint low. We scaled a production app to ₹1 Lakh revenue using just 3 connections on a cheap VPS. Stop overpaying for cloud databases when a tiny VPS can do the job.

Preventing Database Meltdowns: Caching Strategies That Actually Work

Shubham Bhati — Sat, 11 Jul 2026 21:16:02 +0000

When scaling a high-throughput backend, the database is always your primary bottleneck. Every network roundtrip to fetch static or semi-static data wastes CPU cycles and spikes connection pool latency.

To prevent database meltdowns, we implement distributed caching using Redis. But simply throwing @Cacheable on a Spring Boot service method is not enough. You must understand how to manage cache lifecycles.

Here are three production-tested strategies we use to keep systems highly resilient.

1. The Cache-Aside Pattern

This is the most common caching pattern. The application code orchestrates both the cache and the database.

public Account getAccountBalance(Long id) {
    String cacheKey = "account:" + id;
    Account account = redisTemplate.opsForValue().get(cacheKey);

    if (account != null) {
        return account; // Cache Hit
    }

    // Cache Miss
    account = accountRepository.findById(id)
        .orElseThrow(() -> new ResourceNotFoundException("Account not found"));

    redisTemplate.opsForValue().set(cacheKey, account, Duration.ofMinutes(15));
    return account;
}

The Catch: You must ensure cache eviction happens whenever data changes (e.g. during updates) to prevent serving stale data.

2. Guarding Against Cache Penetration (Bloom Filters)

Cache penetration occurs when requests query keys that do not exist in either the cache or the database. If malicious actors flood your API with random IDs, every single request bypasses the cache and hits the database directly.

The Solution: Use a Bloom Filter in front of your cache. A Bloom Filter is a space-efficient probabilistic data structure that can tell you with 100% certainty if an element is not present in the system.
If the Bloom Filter says the ID does not exist, reject the request immediately without hitting Redis or the database.

3. Tuning Time-To-Live (TTL) & Jitter

Setting a hard TTL (like exactly 1 hour) on all keys can cause a Cache Stampede. If 10,000 product keys expire at the exact same second, the next wave of concurrent requests will hit the database at the same time, causing a temporary spike in latency.

The Solution: Add a small randomized delay (jitter) to your TTL. Instead of 60 minutes, set the expiration to 60 + random(1 to 5) minutes. This distributes database read operations smoothly over time.

By combining Cache-Aside with Bloom Filters and randomized TTLs, you protect your primary database from unexpected load spikes.

Concurrency Control in Financial Ledgers: Pessimistic vs Optimistic Locking

Shubham Bhati — Sat, 11 Jul 2026 20:37:07 +0000

When building a high-throughput financial ledger like a digital wallet api, concurrency is the biggest silent killer. If two threads attempt to update the same account balance at the exact same millisecond, you risk duplicate spend or inconsistent ledger entries.

In Java Spring Boot, we typically choose between two main locking strategies: Optimistic and Pessimistic.

1. Optimistic Locking (Using @version)

Optimistic locking assumes conflicts are rare. It uses a version column in the database. When a transaction commits, it checks if the version has changed.

@Entity
public class Account {
    @Id
    private Long id;
    private BigDecimal balance;
    @Version
    private Long version;
}

How it works: Spring Boot executes UPDATE account SET balance = ?, version = version + 1 WHERE id = ? AND version = ?.
The Catch: If another thread updated it first, the version mismatch throws an OptimisticLockingFailureException. The application must handle this by retrying the transaction, which adds latency.

2. Pessimistic Locking (SELECT ... FOR UPDATE)

Pessimistic locking assumes conflicts are highly likely. It explicitly locks the database row at the beginning of the transaction, blocking any other write operations on that row.

@Repository
public interface AccountRepository extends JpaRepository<Account, Long> {
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT a FROM Account a WHERE a.id = :id")
    Optional<Account> findByIdForUpdate(Long id);
}

How it works: Spring Boot translates this to SELECT * FROM account WHERE id = ? FOR UPDATE.
The Catch: Other threads attempting to read or write this row are blocked until the locking transaction commits or rolls back. This prevents optimistic exceptions but requires careful connection pool tuning to avoid thread starvation.

For low-latency wallet services where balances are frequently updated, pessimistic locking is the safest default to prevent double spend.

Optimize HikariCP for Dirt-Cheap VPS Hosting

Shubham Bhati — Sat, 11 Jul 2026 20:29:44 +0000

If you are running a Spring Boot app on a tiny ₹100/month VPS with 1GB RAM, the default settings will crash your server. The biggest silent killer is HikariCP. By default, Spring Boot sets the maximum connection pool size to 10. If you run PostgreSQL, Redis and Spring Boot on the same cheap box, you will quickly hit memory limits.

You don't need 10 connections for low-traffic apps scaling to their first ₹1 Lakh. A pool size of 2 or 3 is more than enough to handle concurrent requests if your queries are indexed properly.

Add this to your application.properties:

spring.datasource.hikari.maximum-pool-size=3
spring.datasource.hikari.minimum-idle=2
spring.datasource.hikari.idle-timeout=30000

This simple tweak slashes RAM usage, prevents database errors and keeps your server alive on tight budgets.

Spring Boot Validation: Don't Reinvent the Wheel

Shubham Bhati — Sat, 11 Jul 2026 20:29:27 +0000

You're building a new API endpoint and need to validate incoming request data. Most of us grab a bunch of if statements. Stop right there. Spring Boot's got your back with JSR 380 (Jakarta Bean Validation).

Just add the spring-boot-starter-validation dependency. Then, annotate your DTO with @Valid and your fields with constraints like @NotNull @Size(min=2 max=10) or @Email. Spring Boot automatically handles validation errors, returning a 400 Bad Request with details. It's way cleaner and more maintainable.

import javax.validation.constraints.Email;
import javax.validation.constraints.NotBlank;
import javax.validation.constraints.Size;

public class UserRequest {
    @NotBlank
    @Size(min = 2 max = 50)
    private String name;

    @NotBlank
    @Email
    private String email;

    // Getters and Setters
}

Then in your controller:

@PostMapping("/users")
public ResponseEntity<?> createUser(@Valid @RequestBody UserRequest request) {
    // ... your logic
    return ResponseEntity.ok("User created");
}

Stop Manual JSON Parsing in Spring Boot

Shubham Bhati — Sat, 11 Jul 2026 05:58:20 +0000

You're probably still writing boilerplate code to parse JSON requests in your Spring Boot controllers. It's 2024 folks! Spring Boot's @RequestBody annotation handles this beautifully out of the box. Just define your Java object and let Spring do the heavy lifting.

Consider this:

@PostMapping("/users")
public ResponseEntity<User> createUser(@RequestBody User newUser) {
    // newUser object is already populated from the JSON request body
    User savedUser = userService.save(newUser);
    return ResponseEntity.status(HttpStatus.CREATED).body(savedUser);
}

This not only cleans up your code but also improves performance slightly by avoiding manual deserialization overhead. Don't reinvent the wheel.

Spring Boot Database Connection Pooling

Shubham Bhati — Fri, 10 Jul 2026 07:02:56 +0000

When working with Spring Boot and PostgreSQL, we've found that connection pooling can make a huge difference in performance. We can't afford to create a new connection for every request, so we use a connection pool to reuse existing connections. Spring Boot makes this easy with the HikariCP library. We just need to add the dependency to our pom.xml file and configure the connection pool properties. For example, we can set the minimum and maximum pool size like this:
@bean
public DataSource dataSource() {
return DataSourceBuilder.create()
.driverClassName("org.postgresql.Driver")
.url("jdbc:postgresql://localhost:5432/mydb")
.username("myuser")
.password("mypassword")
.build();
}
Then we can configure the pool size in our application.properties file: spring.datasource.hikari.minimumPoolSize=5 and spring.datasource.hikari.maximumPoolSize=15. This way, our application doesn't run out of connections when handling a large number of requests.

Don't Let Your Spring Boot App Bleed Redis Memory

Shubham Bhati — Thu, 09 Jul 2026 21:30:50 +0000

You're probably using Redis for caching in your Spring Boot app, right? Great choice. But I've seen apps absolutely tank because of memory bloat in Redis. Often, it's simple cache expiration issues. You set a TTL (Time To Live) but maybe the underlying data is changing too frequently or your eviction policy isn't aggressive enough.

Here's a quick check. In your application.properties or application.yml, make sure your spring.redis.client-type is set to lettuce (it's the default and generally good) and then focus on your eviction policy. If you're using RedisTemplate, ensure your cache configurations are sound. Something like this, for instance, isn't enough on its own if your data churns:

// Example: Without proper eviction policy, this might still cause bloat
@Bean
public RedisCacheManager cacheManager(RedisConnectionFactory redisConnectionFactory) {
    RedisCacheConfiguration cacheConfig = RedisCacheConfiguration.defaultCacheConfig()
            .entryTtl(Duration.ofMinutes(5)); // This is just expiration
    return RedisCacheManager.builder(redisConnectionFactory)
            .cacheWriter(RedisCacheWriter.lockingRedisCacheWriter(redisConnectionFactory))
            .withCacheConfiguration("myCache", cacheConfig)
            .build();
}

Instead, consider setting an eviction policy like ALLKEYS_LRU or VOLATILE_LRU directly in your redis.conf or via Redis commands. It means Redis will actively kick out less recently used items when it needs space, saving you from those surprise memory bills.

Simplifying Database Connections with Spring Boot

Shubham Bhati — Thu, 09 Jul 2026 19:43:51 +0000

When building microservices with Spring Boot we often need to connect to multiple databases. To simplify this process we can use the @Configuration annotation to define a separate configuration class for our database connections. For example we can create a class called DatabaseConfig that defines a bean for our PostgreSQL database connection.

@Configuration
public class DatabaseConfig {
    @Bean
    public DataSource dataSource() {
        return DataSourceBuilder.create()
                .driverClassName("org.postgresql.Driver")
                .url("jdbc:postgresql://localhost:5432/mydb")
                .username("myuser")
                .password("mypassword")
                .build();
    }
}

This way we can easily manage our database connections and switch between different databases if needed. We can also use this configuration class to define multiple data sources for different databases.