DEV Community: Shubham Bhati

Asynchronous Programming in Spring Boot with CompletableFuture

Shubham Bhati — Thu, 06 Aug 2026 14:14:29 +0000

Published 2026-08-06 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

Turbocharge Your Spring Boot APIs: Mastering Asynchronous Programming with CompletableFuture

Hey there, fellow backend engineers! Shubham Bhati here. Ever stared at slow API response times in production, seeing those P99 latencies climb because your service is waiting endlessly for an external API or a database query? You've got a Spring Boot application that's doing important work, but synchronous I/O can quickly turn your powerful server into a bottleneck. It's frustrating to know your server is underutilized while threads are blocked. This is exactly where spring boot async completablefuture comes in, empowering you to build truly non-blocking, high-performance services. Let's dive into how to leverage this pattern to keep your application snappy and your users happy.

The Bottleneck: Synchronous Spring Boot APIs

Imagine a typical Spring Boot REST endpoint. A client makes a request, your controller calls a service, which in turn might fetch data from a database or another microservice. If these downstream calls are slow, your current request thread is blocked, sitting idle until the operation completes. For a busy application, this quickly exhausts your web server's thread pool (like Tomcat's default server.tomcat.threads.max of 200). Once all threads are blocked, new incoming requests simply queue up or get rejected.

This blocking behavior directly impacts your API's throughput and latency. Even if your average response time is good, those P99 (99th percentile) latency spikes indicate many users are having a terrible experience. Let's look at a typical synchronous service call:

// Synchronous service method
@Service
public class ProductService {
    public ProductData getProductDetails(String productId) {
        // Simulate a slow external call or DB operation
        try {
            Thread.sleep(2000); // 2-second blocking operation
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        return new ProductData(productId, "Awesome Widget", 99.99);
    }
}

// Synchronous controller
@RestController
@RequestMapping("/api/products")
public class ProductController {
    @Autowired
    private ProductService productService;

    @GetMapping("/{productId}")
    public ProductData getProduct(@PathVariable String productId) {
        return productService.getProductDetails(productId); // Blocking call
    }
}

In a production scenario, having many such blocking calls will drastically reduce your application's capacity and introduce unpredictable latency, leading to unhappy users and overloaded servers.

Embracing Asynchronicity with `@Async` and `CompletableFuture`

Spring Boot provides a straightforward way to make methods execute asynchronously using the @Async annotation. When a method marked with @Async is called, Spring executes it in a separate thread from a thread pool. To use it, you first need to enable asynchronous processing in your main application class or a configuration class with @EnableAsync.

The magic truly happens when you combine @Async with CompletableFuture. Instead of blocking and waiting for a result, your method immediately returns a CompletableFuture. This object represents a future result that will be available eventually. Your calling code can then compose operations on this future without blocking, or simply wait for it using join() or get() (though ideally, you'd avoid blocking as much as possible).

// Enable async processing
@SpringBootApplication
@EnableAsync
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

// Asynchronous service method
@Service
public class ProductService {
    @Async("productExecutor") // Use a named executor
    public CompletableFuture<ProductData> getProductDetailsAsync(String productId) {
        // Simulate a slow external call or DB operation
        try {
            Thread.sleep(2000); // 2-second blocking operation
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return CompletableFuture.failedFuture(e); // Propagate interruption
        }
        return CompletableFuture.completedFuture(new ProductData(productId, "Awesome Widget", 99.99));
    }
}

// Controller using async service
@RestController
@RequestMapping("/api/products")
public class ProductController {
    @Autowired
    private ProductService productService;

    @GetMapping("/{productId}")
    public CompletableFuture<ProductData> getProduct(@PathVariable String productId) {
        return productService.getProductDetailsAsync(productId); // Non-blocking!
    }
}

Now, your controller method immediately returns a CompletableFuture, allowing the web server thread to be released back to handle other requests. Spring will handle the CompletableFuture return type, asynchronously sending the response when the future completes. This significantly improves server resource utilization.

Fine-Tuning Asynchronous Execution: Custom Thread Pools

While @Async is powerful, using Spring's default SimpleAsyncTaskExecutor in production is a bad idea. It creates a new thread for every async invocation, which can quickly exhaust system resources and lead to performance degradation. For production applications, you must configure a dedicated ThreadPoolTaskExecutor.

A custom ThreadPoolTaskExecutor allows you to define a fixed pool of threads, preventing unbounded thread creation. You can specify corePoolSize, maxPoolSize, queueCapacity, and a threadNamePrefix for easier monitoring. This ensures predictable resource usage and better control over your asynchronous operations. Remember, if your async tasks involve database operations, ensure your maxPoolSize doesn't exceed your HikariCP connection pool size, otherwise you risk connection starvation.

@Configuration
@EnableAsync
public class AsyncConfig implements AsyncConfigurer {

    @Override
    public Executor getAsyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5); // Minimum number of threads
        executor.setMaxPoolSize(10); // Maximum number of threads
        executor.setQueueCapacity(25); // Queue for tasks when all core threads are busy
        executor.setThreadNamePrefix("ProductAsync-"); // Prefix for thread names
        executor.initialize();
        return executor;
    }

    // You can define multiple executors and refer to them by name in @Async
    @Bean(name = "productExecutor")
    public Executor productExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(3);
        executor.setMaxPoolSize(5);
        executor.setQueueCapacity(10);
        executor.setThreadNamePrefix("SpecificProduct-");
        executor.initialize();
        return executor;
    }
}

By explicitly defining a ThreadPoolTaskExecutor, you gain critical control. You can tune the pool size based on the nature of your async tasks (CPU-bound vs. I/O-bound) and monitor its performance. This prevents memory footprint issues from too many threads and ensures your server remains responsive under load. Without this, your async efforts could ironically lead to worse performance.

Common Pitfalls

When working with spring boot async completablefuture, watch out for these common issues:

Missing @EnableAsync: Forgetting this annotation will cause your @Async methods to execute synchronously.
Calling @Async from the same class: @Async methods must be called from another Spring-managed bean for the proxying to work. Calling this.myAsyncMethod() from within the same service will bypass the proxy and execute synchronously.
Ignoring CompletableFuture error handling: If an asynchronous task throws an exception, it won't be rethrown immediately. You must explicitly handle exceptions using exceptionally(), handle(), or whenComplete() on the CompletableFuture object to prevent silent failures.
Using default SimpleAsyncTaskExecutor in production: As discussed, this executor creates a new thread for every call, leading to resource exhaustion. Always configure a custom ThreadPoolTaskExecutor.
ThreadLocal issues: State stored in ThreadLocal variables (e.g., security context, MDC for logging) does not automatically propagate to the new thread created by @Async. You might need custom solutions or Spring's RequestContextFilter if using a Callable.

Conclusion

Asynchronous programming with CompletableFuture and Spring's @Async annotation is a powerful tool in any Java backend engineer's arsenal. It transforms your Spring Boot applications from blocking, thread-heavy services into efficient, non-blocking powerhouses. By carefully configuring custom thread pools and understanding the nuances, you can dramatically improve your API's throughput, reduce latency, and make better use of your server resources. Start incorporating these patterns today to build more resilient and performant microservices.

Asynchronous Programming in Spring Boot with CompletableFuture

Shubham Bhati — Wed, 05 Aug 2026 14:13:17 +0000

Published 2026-08-05 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

Asynchronous Programming in Spring Boot with CompletableFuture

Hey fellow backend engineers! Shubham Bhati here. Ever stared at a slow API endpoint, knowing a single request is waiting for multiple downstream services or complex computations? Your users are frustrated, and your P99 latency numbers are climbing. In a microservices architecture, this synchronous "waterfall" of calls can cripple performance. But what if you could kick off these independent tasks concurrently, speeding up response times significantly? That's where spring boot async completablefuture comes in, transforming your blocking operations into non-blocking, high-performance powerhouses. Let's dive into how you can make your Spring Boot applications truly reactive and efficient.

Unleashing @async: The Foundation

Spring Boot makes asynchronous execution surprisingly simple with @EnableAsync and @Async. Annotate your main application class (or any @Configuration class) with @EnableAsync to tell Spring to look for @Async methods. Then, just place @Async on any public method in a Spring-managed bean that you want to run on a separate thread. This is fantastic for fire-and-forget tasks or when you need a method to return a CompletableFuture for later processing.

Consider a scenario where you're sending an email notification after a user action. This doesn't need to block the main request thread.

// In your Spring Boot application class or a @Configuration class
@SpringBootApplication
@EnableAsync // Don't forget this!
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

// In your service layer
@Service
public class NotificationService {

    @Async
    public CompletableFuture<Void> sendWelcomeEmail(String userId) {
        System.out.println("Sending welcome email for user: " + userId + " on thread: " + Thread.currentThread().getName());
        try {
            Thread.sleep(2000); // Simulate network latency or heavy work
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        System.out.println("Email sent for user: " + userId);
        return CompletableFuture.completedFuture(null);
    }
}

When sendWelcomeEmail is called from another Spring bean, it executes on a separate thread, letting the calling thread continue immediately. While convenient, Spring's default SimpleAsyncTaskExecutor creates a new thread for every @Async call, which is a significant production concern. This unbounded thread creation can quickly exhaust system resources, leading to instability or even OutOfMemoryErrors. Always configure a proper thread pool in production environments.

Configuring a Custom Thread Pool

Relying on Spring's default TaskExecutor for @Async is a common trap. For production-grade applications, you absolutely need to define a custom ThreadPoolTaskExecutor. This allows you to control the number of threads, queue capacity, and how rejected tasks are handled, preventing your application from spinning up too many threads and crashing under load. This dedicated executor provides a bounded, managed pool of threads for your asynchronous operations.

Let's set up a custom TaskExecutor to power our @Async methods:

@Configuration
public class AsyncConfig {

    @Bean(name = "taskExecutor")
    public TaskExecutor taskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5); // Minimum number of threads
        executor.setMaxPoolSize(10); // Maximum number of threads
        executor.setQueueCapacity(25); // Queue for tasks when all core threads are busy
        executor.setThreadNamePrefix("MyAsyncTask-");
        // What to do if the queue is full and max threads are busy?
        // CallerRunsPolicy makes the calling thread run the task.
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        executor.initialize();
        return executor;
    }
}

Now, @Async methods will use this taskExecutor bean. You can define multiple TaskExecutor beans and specify which one an @Async method should use: @Async("mySpecificExecutor"). Careful tuning of corePoolSize, maxPoolSize, and queueCapacity is critical. For I/O-bound tasks (like external API calls, database queries), you often want a larger maxPoolSize relative to corePoolSize to handle periods of high concurrency. For CPU-bound tasks, corePoolSize typically aligns with the number of available CPU cores to avoid excessive context switching. Always monitor your thread pool metrics in production to fine-tune these values.

Mastering CompletableFuture for Orchestration

While @Async gives you concurrency, CompletableFuture (introduced in Java 8) gives you powerful, non-blocking composition and orchestration. Instead of blocking with Future.get(), you can chain operations, transform results, and combine multiple asynchronous computations efficiently. This is the real magic for improving perceived latency and handling complex workflows.

Imagine fetching user details from one service and their order history from another, both concurrently.

@Service
public class UserService {

    public CompletableFuture<User> fetchUserDetails(String userId) {
        return CompletableFuture.supplyAsync(() -> {
            System.out.println("Fetching user details for " + userId + " on " + Thread.currentThread().getName());
            try { Thread.sleep(1500); } catch (InterruptedException e) { Thread.currentThread().interrupt(); }
            return new User(userId, "Shubham Bhati");
        }, asyncConfig.taskExecutor()); // Use our custom executor

    }

    public CompletableFuture<List<Order>> fetchUserOrders(String userId) {
        return CompletableFuture.supplyAsync(() -> {
            System.out.println("Fetching orders for " + userId + " on " + Thread.currentThread().getName());
            try { Thread.sleep(2000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); }
            return List.of(new Order("ORD-001"), new Order("ORD-002"));
        }, asyncConfig.taskExecutor());
    }

    public CompletableFuture<UserProfile> getUserProfile(String userId) {
        CompletableFuture<User> userFuture = fetchUserDetails(userId);
        CompletableFuture<List<Order>> ordersFuture = fetchUserOrders(userId);

        // Combine both results once they are available
        return CompletableFuture.allOf(userFuture, ordersFuture)
                .thenApply(v -> { // 'v' is Void as allOf doesn't return results directly
                    try {
                        User user = userFuture.get();
                        List<Order> orders = ordersFuture.get();
                        return new UserProfile(user, orders);
                    } catch (Exception e) {
                        throw new RuntimeException("Failed to get user profile", e);
                    }
                })
                .exceptionally(ex -> { // Handle errors
                    System.err.println("Error getting user profile: " + ex.getMessage());
                    return new UserProfile(new User(userId, "N/A"), Collections.emptyList()); // Fallback or throw
                });
    }
}

This getUserProfile method fetches user and order details concurrently. CompletableFuture.allOf waits for both to complete without blocking the calling thread. thenApply then transforms their results into a UserProfile. Always include .exceptionally() to gracefully handle errors in your CompletableFuture chains. Using CompletableFuture for such orchestrations drastically improves latency and resource utilization, especially for I/O bound tasks.

Common Pitfalls

Forgetting @EnableAsync: Your @Async methods won't run asynchronously without this. Spring just ignores the annotation.
Calling @Async from the same class: @Async works via Spring AOP proxies. If this.asyncMethod() is called from within the same bean, the proxy isn't invoked, and the method runs synchronously. Inject the bean into itself (carefully!) or move the @Async method to a separate service.
No custom TaskExecutor: Relying on Spring's default SimpleAsyncTaskExecutor for @Async in production is a recipe for resource exhaustion and instability.
Ignoring CompletableFuture exceptions: Unhandled exceptions in CompletableFuture chains can disappear or lead to obscure failures. Always use .exceptionally(), .handle(), or .whenComplete() for proper error management.
Blocking on CompletableFuture.get(): Calling future.get() immediately after submitting an async task defeats the purpose of asynchronous programming, as it blocks the current thread until the result is available. Use thenApply, thenCompose, allOf, or anyOf for non-blocking composition.

Conclusion

Asynchronous programming with CompletableFuture and @Async is a crucial skill for modern Spring Boot backend development. It lets you build responsive, high-throughput applications by efficiently handling I/O bound operations and concurrent computations. Remember to always configure a custom thread pool for @Async and master CompletableFuture's powerful composition methods. Embrace these tools, and you'll significantly boost your application's performance, delivering a smoother experience for your users and a more resilient service overall. Happy coding!

Asynchronous Programming in Spring Boot with CompletableFuture

Shubham Bhati — Tue, 04 Aug 2026 14:19:27 +0000

Published 2026-08-04 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

Asynchronous Programming in Spring Boot with CompletableFuture

Author: Shubham Bhati, Backend Engineer (Java 17, Spring Boot, Microservices)

Ever faced a situation where a single API request triggers multiple independent calls to external services or databases? Waiting for each call to complete sequentially can quickly inflate your response times, pushing p99 latency metrics through the roof. This bottleneck often degrades user experience and strains server resources. Spring Boot's asynchronous capabilities, particularly with Java's CompletableFuture, offer a powerful solution. By enabling concurrent execution of these independent operations, you can dramatically cut down processing time, making your applications more responsive and efficient. Let's explore how to implement this effectively.

Getting Started with `@Async`

Spring Boot makes asynchronous method execution incredibly simple with the @Async annotation. To enable it, you first need @EnableAsync on one of your configuration classes. Then, mark any method that should run in a separate thread with @Async. Spring will intercept these calls and execute them in a different thread from the caller. This is perfect for fire-and-forget operations or tasks that don't immediately return a value.

// Main Spring Boot Application class
@SpringBootApplication
@EnableAsync // Don't forget this!
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

// Example Async Service
@Service
public class EmailService {

    @Async
    public void sendWelcomeEmail(String userEmail) {
        // Simulate a time-consuming email sending process
        try {
            Thread.sleep(2000); // 2 seconds delay
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        System.out.println("Email sent to: " + userEmail + " from thread: " + Thread.currentThread().getName());
    }
}

By default, @Async uses Spring's SimpleAsyncTaskExecutor, which creates a new thread for every async invocation. While easy to use, this default can quickly exhaust system resources under high load, potentially leading to OutOfMemoryError or thread starvation. For production environments, configuring a custom TaskExecutor is non-negotiable for stability and performance.

Customizing Your Async Thread Pool

To prevent resource exhaustion and gain fine-grained control over asynchronous task execution, you must define and configure a custom TaskExecutor. This allows you to manage the number of active threads, queue capacity and thread naming conventions, aligning them with your application's specific workload characteristics. A ThreadPoolTaskExecutor is the go-to choice, letting you pre-configure a pool of threads ready to handle async tasks.

// Spring Configuration for custom TaskExecutor
@Configuration
public class AsyncConfig {

    @Bean(name = "threadPoolTaskExecutor")
    public TaskExecutor threadPoolTaskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5);          // Minimum number of threads
        executor.setMaxPoolSize(10);          // Maximum number of threads
        executor.setQueueCapacity(25);        // Queue size for tasks when all core threads are busy
        executor.setThreadNamePrefix("AsyncService-");
        executor.initialize();
        return executor;
    }
}

When marking an @Async method, you can specify which TaskExecutor to use: @Async("threadPoolTaskExecutor"). Correctly sizing your thread pool (corePoolSize, maxPoolSize, queueCapacity) is critical. For I/O-bound tasks (like external API calls or database queries), you might need a larger pool than for CPU-bound tasks. Over-provisioning can lead to excessive context switching, while under-provisioning causes task backlogs. Remember to monitor your application's thread usage and HikariCP connection pools to ensure your async operations don't starve other critical resources.

Mastering `CompletableFuture` for Complex Flows

While @Async is great for simple fire-and-forget, CompletableFuture shines when you need to combine results from multiple asynchronous operations, chain them together, or handle errors gracefully. It allows you to write non-blocking code that reacts to the completion of a future computation, rather than waiting. This makes your application more reactive and significantly improves p99 latency for complex requests.

// Service method returning CompletableFuture
@Service
public class ProductService {

    @Autowired
    private ProductApiClient productApiClient; // Simulating external API

    @Async("threadPoolTaskExecutor") // Using our custom executor
    public CompletableFuture<String> fetchProductDetails(String productId) {
        return CompletableFuture.supplyAsync(() -> {
            // Simulate network call latency
            try {
                Thread.sleep(1500);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            return "Details for product " + productId;
        }, threadPoolTaskExecutor()); // Ensure CompletableFuture uses the custom executor
    }

    public String getCombinedProductInfo(String productId) {
        CompletableFuture<String> detailsFuture = fetchProductDetails(productId);
        CompletableFuture<String> inventoryFuture = fetchInventoryInfo(productId); // Another async call

        // Combine results
        return CompletableFuture.allOf(detailsFuture, inventoryFuture)
                .thenApply(v -> detailsFuture.join() + ", " + inventoryFuture.join())
                .exceptionally(ex -> "Error fetching product info: " + ex.getMessage())
                .join(); // Blocks here to get the final result
    }

    @Async("threadPoolTaskExecutor")
    private CompletableFuture<String> fetchInventoryInfo(String productId) {
        return CompletableFuture.supplyAsync(() -> {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            return "Inventory for product " + productId + ": 15 units";
        }, threadPoolTaskExecutor());
    }
}

CompletableFuture provides methods like thenApply, thenCompose, thenAccept, and allOf for chaining operations and aggregating results. Always include .exceptionally() for proper error handling. When using CompletableFuture.supplyAsync() or CompletableFuture.runAsync(), remember to pass your custom TaskExecutor (or an Executor directly) to ensure they run on your managed thread pool, not the default ForkJoinPool.commonPool(). This control is vital for maintaining predictable memory footprint and avoiding resource contention.

Common Pitfalls

Not configuring a custom TaskExecutor: Relying on the default SimpleAsyncTaskExecutor or ForkJoinPool.commonPool() can lead to OutOfMemoryError or unexpected performance issues under load. Always define and use your own ThreadPoolTaskExecutor.
Forgetting to join() or get() on a CompletableFuture: If your calling method needs the result of an asynchronous computation, you must block to retrieve it. Forgetting this means your calling method might proceed without the necessary data, or the async task's results are simply discarded.
Not handling exceptions in CompletableFuture chains: Unhandled exceptions in CompletableFuture can silently terminate threads or leave tasks in a "completed exceptionally" state without proper logging or fallback mechanisms. Always include .exceptionally() or .handle() for resilient error management.
Blocking CompletableFuture.allOf().join() too early: While allOf().join() waits for all futures to complete, ensure you're calling it from a context that can tolerate blocking, or better, chain another thenApply or thenAccept to process results non-blockingly.

Conclusion

Asynchronous programming with Spring Boot and CompletableFuture is a powerful pattern for building high-performance, responsive backend services. By correctly configuring custom thread pools and leveraging the rich API of CompletableFuture, you can efficiently manage concurrent operations, drastically reduce latency, and improve resource utilization. Start optimizing your Spring Boot applications today by embracing these patterns, making your services faster and more resilient to varying loads.

Asynchronous Programming in Spring Boot with CompletableFuture

Shubham Bhati — Mon, 03 Aug 2026 22:50:49 +0000

Published 2026-08-03 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

Supercharge Your Spring Boot Apps: Mastering Asynchronous Operations with CompletableFuture

Hey fellow backend engineers! Shubham Bhati here. Ever stared at your Prometheus dashboard, watching API latency spike into the hundreds of milliseconds because a single request had to hit multiple external services? That blocking I/O waiting game is a killer for user experience and server efficiency. If your Spring Boot application is struggling with sluggish response times due to sequential calls to databases, third-party APIs or message queues, it's time to go async. We're talking about embracing CompletableFuture with spring boot async completablefuture to parallelize tasks and reclaim those precious milliseconds, giving your applications the performance boost they deserve.

Kickstarting Asynchronicity with `@Async`

The simplest way to introduce java async behavior in Spring Boot is with the @Async annotation. It's incredibly straightforward: mark a method with @Async, and Spring will execute it in a separate thread. First, you need to enable async processing in your main application class or a configuration class using @EnableAsync. Then, any method within a Spring-managed bean annotated with @Async will be executed by a ThreadPoolTaskExecutor managed by Spring. This immediately frees up the calling thread to continue its work, preventing it from blocking.

Consider a scenario where you need to send an email notification after a user action, but the user doesn't need to wait for the email to be fully sent.

// Main Application Class
@SpringBootApplication
@EnableAsync
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

// EmailService.java
@Service
public class EmailService {

    @Async
    public void sendWelcomeEmail(String userEmail) {
        System.out.println("Sending welcome email to: " + userEmail + " in thread: " + Thread.currentThread().getName());
        try {
            Thread.sleep(2000); // Simulate network latency or complex email templating
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        System.out.println("Email sent to: " + userEmail);
    }
}

Production Note: While @Async is easy, relying on Spring's default SimpleAsyncTaskExecutor is often insufficient for production. It creates a new thread for every task, which can quickly lead to thread exhaustion and out-of-memory errors under high load. For any serious spring async annotation usage, you'll want to configure a custom thread pool.

Custom Thread Pools: The Foundation of Control

To prevent unbounded thread creation and manage resources effectively, you must configure a custom ThreadPoolTaskExecutor for your @Async methods. This gives you granular control over thread count, queue capacity, and rejection policies. A well-configured thread pool ensures your application can handle concurrent async tasks without compromising stability or performance. You need to provide a custom Executor bean, and Spring will use it for @Async methods if present.

Here's how to set up a dedicated thread pool for your async tasks:

// AsyncConfig.java
@Configuration
@EnableAsync
public class AsyncConfig {

    @Bean(name = "taskExecutor")
    public ThreadPoolTaskExecutor taskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5); // Number of threads always alive
        executor.setMaxPoolSize(10); // Max number of threads that can be created
        executor.setQueueCapacity(25); // Queue for tasks when all threads are busy
        executor.setThreadNamePrefix("AsyncService-"); // Prefix for thread names
        executor.initialize();
        return executor;
    }
}

// In your service method, specify the executor
@Service
public class NotificationService {

    @Async("taskExecutor") // Use the named executor
    public CompletableFuture<String> sendSmsNotification(String phoneNumber) {
        System.out.println("Sending SMS to: " + phoneNumber + " in thread: " + Thread.currentThread().getName());
        try {
            Thread.sleep(1500); // Simulate external SMS API call
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return CompletableFuture.completedFuture("SMS failed for " + phoneNumber);
        }
        return CompletableFuture.completedFuture("SMS sent to " + phoneNumber);
    }
}

Production Note: Sizing your thread pool is crucial. For CPU-bound tasks, corePoolSize should be close to the number of CPU cores. For I/O-bound tasks (like external API calls), it can be much larger, as threads spend most of their time waiting. Monitor your thread pool metrics (active threads, queue size, completed tasks) to tune it for optimal performance and to avoid latency p99 spikes caused by overloaded queues or thread contention.

`CompletableFuture`: Unleashing True Asynchronicity

While @Async runs methods in a separate thread, CompletableFuture provides a powerful API for chaining, combining, and handling results of java async operations in a non-blocking way. It's the go-to for situations where you need to perform multiple independent tasks concurrently and then aggregate their results, or when one task depends on the outcome of another. CompletableFuture allows you to write highly concurrent, reactive code that significantly improves perceived performance. It's not just about fire-and-forget; it's about orchestration.

Imagine fetching user details and their order history concurrently, then combining them.

@Service
public class UserService {

    @Async("taskExecutor") // Even with CompletableFuture, @Async uses a custom executor
    public CompletableFuture<User> fetchUserDetails(String userId) {
        return CompletableFuture.supplyAsync(() -> {
            System.out.println("Fetching user details for " + userId + " in thread: " + Thread.currentThread().getName());
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            return new User(userId, "John Doe");
        }, AsyncConfig.taskExecutor()); // Explicitly provide executor if not using @Async
    }

    @Async("taskExecutor")
    public CompletableFuture<List<Order>> fetchUserOrders(String userId) {
        return CompletableFuture.supplyAsync(() -> {
            System.out.println("Fetching orders for " + userId + " in thread: " + Thread.currentThread().getName());
            try {
                Thread.sleep(150);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            return Arrays.asList(new Order("1", 100.0), new Order("2", 250.0));
        }, AsyncConfig.taskExecutor());
    }

    public CompletableFuture<CombinedUserData> getCombinedData(String userId) {
        CompletableFuture<User> userFuture = fetchUserDetails(userId);
        CompletableFuture<List<Order>> ordersFuture = fetchUserOrders(userId);

        return CompletableFuture.allOf(userFuture, ordersFuture)
                .thenApply(v -> {
                    try {
                        User user = userFuture.get();
                        List<Order> orders = ordersFuture.get();
                        return new CombinedUserData(user, orders);
                    } catch (Exception e) {
                        throw new RuntimeException("Failed to combine user data", e);
                    }
                });
    }
}

Production Note: CompletableFuture can reduce latency p99 by running independent operations in parallel. Pay attention to error handling with exceptionally() or handle() to prevent silent failures. Be mindful of memory footprint if you're holding onto many CompletableFuture instances and their results; ensure you're consuming results and releasing references efficiently.

Common Pitfalls

Not configuring a custom ThreadPoolTaskExecutor: Relying on Spring's default SimpleAsyncTaskExecutor can lead to performance degradation and OutOfMemoryErrors in production environments due to unlimited thread creation.
Blocking inside @Async methods: If your async method still performs blocking I/O (like a synchronous database call or external API call without an async client), you're still blocking a thread pool thread, defeating the purpose of asynchronicity for that task.
Ignoring error handling: CompletableFuture tasks can fail silently if you don't use methods like exceptionally() or handle() to explicitly manage exceptions. This makes debugging incredibly difficult.
Misunderstanding CompletableFuture.get(): Calling .get() on a CompletableFuture blocks the calling thread until the result is available. While necessary sometimes, overuse negates the non-blocking benefits.

Conclusion

Mastering spring boot async completablefuture is a vital skill for building high-performance, responsive backend services. By correctly using @Async with a custom thread pool and orchestrating complex workflows with CompletableFuture, you can significantly reduce API response times, improve resource utilization, and deliver a better user experience. Start refactoring those blocking operations today and unlock the true potential of your Spring Boot applications. Happy coding!

Asynchronous Programming in Spring Boot with CompletableFuture

Shubham Bhati — Mon, 03 Aug 2026 14:43:08 +0000

Published 2026-08-03 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

Hey there, Shubham Bhati here.

Mastering Asynchronous Programming in Spring Boot with CompletableFuture

Ever faced an API that felt sluggish, taking seconds to respond because it was sequentially calling multiple external services or performing intensive computations? You’re not alone. In production, a single slow dependency can cripple user experience and impact p99 latency metrics significantly. This is where spring boot async completablefuture comes to the rescue, allowing your applications to perform non-blocking operations, execute tasks concurrently, and deliver snappy responses. By embracing asynchronous programming, we can boost our application's scalability and responsiveness, turning those agonizing waits into instant feedback. Let's dive into how you can transform your Spring Boot services.

Enabling Asynchronous Execution

To kickstart asynchronous operations in Spring Boot, we first need to enable it using @EnableAsync on your main application class or a configuration class. Then, any method annotated with @Async will run in a separate thread. While @Async methods can return void or Future<T>, CompletableFuture<T> is often preferred for its richer API for chaining and combining results. For simple fire-and-forget or isolated tasks, @Async is a powerful starting point. Remember, calling @Async methods from within the same class won't work due to Spring's AOP proxying.

@SpringBootApplication
@EnableAsync
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

@Service
public class ProductService {

    @Async
    public CompletableFuture<String> fetchProductDetails(String productId) {
        // Simulate a long-running external API call or computation
        try {
            Thread.sleep(2000); // 2 seconds delay
            System.out.println("Fetching details for: " + productId + " in thread: " + Thread.currentThread().getName());
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        return CompletableFuture.completedFuture("Details for " + productId);
    }
}

Production Note: The default SimpleAsyncTaskExecutor creates a new thread for every @Async call. This is highly inefficient and dangerous in production, potentially leading to memory exhaustion and thread pool starvation under load. Always configure a custom ThreadPoolTaskExecutor.

Configuring a Custom Thread Pool

Relying on Spring's default SimpleAsyncTaskExecutor for @Async methods is a fast track to production woes. For real-world applications, you must define and provide a custom ThreadPoolTaskExecutor. This allows you fine-grained control over the number of threads, queue capacity, and how your application handles thread saturation. Proper thread pool sizing prevents your application from crashing under heavy load and ensures efficient resource utilization. Consider your application's workload characteristics when setting corePoolSize, maxPoolSize, and queueCapacity.

@Configuration
public class AsyncConfig {

    @Bean(name = "taskExecutor")
    public ThreadPoolTaskExecutor taskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5);         // Minimum active threads
        executor.setMaxPoolSize(10);         // Maximum threads for bursts
        executor.setQueueCapacity(25);       // Queue for waiting tasks
        executor.setThreadNamePrefix("AsyncService-");
        executor.initialize();
        return executor;
    }
}

When calling @Async methods, Spring will use this configured executor. If you have multiple executors, specify the bean name: @Async("taskExecutor"). Production Note: Monitor your thread pool's queue depth and active threads. A consistently full queue or high active thread count can indicate your maxPoolSize is too low, or your backend services are struggling. Use tools like Prometheus or Micrometer to track these metrics. Improper tuning can lead to latency spikes (p99) or even service unavailability.

Composing Asynchronous Operations with CompletableFuture

CompletableFuture goes beyond simple @Async by providing a powerful API for chaining, combining, and handling results of multiple asynchronous computations. You can fetch data from several independent services concurrently, then combine their results, or execute subsequent tasks based on the outcome of a previous one. This greatly improves overall response times for complex operations by reducing blocking I/O. Methods like supplyAsync, thenApply, thenCompose, allOf, and anyOf are your go-to tools for orchestrating concurrent tasks.

@Service
public class OrderService {

    @Autowired
    private ProductService productService; // Our @Async service

    public CompletableFuture<String> processOrder(String orderId) {
        long startTime = System.currentTimeMillis();

        CompletableFuture<String> product1Future = productService.fetchProductDetails("PROD-001");
        CompletableFuture<String> product2Future = productService.fetchProductDetails("PROD-002");

        // Combine results when both futures complete
        return CompletableFuture.allOf(product1Future, product2Future)
                .thenApply(v -> {
                    try {
                        String details1 = product1Future.get();
                        String details2 = product2Future.get();
                        long endTime = System.currentTimeMillis();
                        System.out.println("Combined processing time: " + (endTime - startTime) + "ms");
                        return "Order " + orderId + " processed with: " + details1 + " and " + details2;
                    } catch (Exception e) {
                        throw new RuntimeException("Failed to get product details", e);
                    }
                })
                .exceptionally(ex -> {
                    System.err.println("Error processing order: " + ex.getMessage());
                    return "Order " + orderId + " failed due to: " + ex.getMessage();
                });
    }
}

Production Note: Always implement robust error handling with exceptionally or handle to prevent silent failures. Unhandled exceptions in CompletableFuture can lead to deadlocks or tasks never completing. For I/O-bound tasks, consider using a separate ForkJoinPool or Virtual Threads in Java 21+ for even better resource utilization, especially for highly concurrent workloads.

Common Pitfalls

No Custom ThreadPoolTaskExecutor: Relying on the default SimpleAsyncTaskExecutor is a performance bottleneck and can lead to out-of-memory errors under load.
Calling @Async from Same Class: Spring's proxying mechanism means @Async annotations are not intercepted when called internally. Use a self-injected proxy or separate service.
Ignoring Exception Handling: CompletableFuture exceptions are silently swallowed if not explicitly handled with exceptionally or handle. This makes debugging extremely difficult.
Blocking on CompletableFuture.get(): If you block indefinitely on future.get() right after submitting an async task, you negate most of the benefits of asynchronous programming. Use chaining methods like thenApply or allOf.
Large Queue Sizes: An excessively large queueCapacity can hide underlying performance problems, leading to high memory footprint and increased latency for tasks waiting in the queue.

Conclusion

Asynchronous programming with CompletableFuture and @Async in Spring Boot is an essential technique for building high-performance, scalable backend services. By correctly configuring custom thread pools and leveraging the rich API of CompletableFuture, you can significantly reduce API response times, improve resource utilization and deliver a superior user experience. Embrace these patterns to ensure your Spring Boot applications are ready for the demands of production traffic. Happy coding!

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Shubham Bhati — Sun, 02 Aug 2026 13:25:44 +0000

Published 2026-08-02 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Remember the early days of microservices? Deploying a dozen services only to realize they could not find each other without hardcoding IP addresses and ports? What a nightmare when scaling, deploying new versions, or handling failures! Manual updates to configuration files became a bottleneck, making continuous deployment feel like a distant dream. This problem is precisely what service discovery solves, enabling services to dynamically find and communicate with one another. In this spring cloud eureka tutorial, we will get our hands dirty setting up a Eureka server and clients to bring order to your microservice chaos.

Setting Up Your Eureka Server

The Eureka Server acts as a central registry where all your microservices register themselves. It keeps track of service instances, their locations, and health statuses. Building one with Spring Boot is surprisingly straightforward. You start by adding the spring-cloud-starter-netflix-eureka-server dependency to your pom.xml. Then, simply annotate your main application class with @EnableEurekaServer.

<!-- pom.xml -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

// EurekaServerApplication.java
@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

Next, configure the server in your application.yml. You generally want to disable registration and fetching from itself, as it's the server. It is typically a lean service, so its memory footprint is low, consuming only what's needed for the registry data. But watch out for port conflicts if you run multiple services on the same host during local development.

# application.yml for Eureka Server
server:
  port: 8761

eureka:
  client:
    register-with-eureka: false
    fetch-registry: false

Registering a Client Service

Now that our Eureka server is ready, client microservices can register themselves. This means they broadcast their network location and status to the registry. To enable this in a Spring Boot service, add the spring-cloud-starter-netflix-eureka-client dependency. Crucially, annotate your main application class with @EnableDiscoveryClient.

<!-- pom.xml -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

// MyServiceClientApplication.java
@SpringBootApplication
@EnableDiscoveryClient
public class MyServiceClientApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyServiceClientApplication.class, args);
    }
}

In your client service's application.yml, point it to your Eureka server. You will also give your service an application-name which other services will use to find it. The Eureka client intelligently caches the service registry, which makes your service more resilient to temporary Eureka server outages. This local cache minimizes registration latency and reduces direct dependencies on the server for every service lookup.

# application.yml for Client Service
spring:
  application:
    name: my-service-client

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/
  instance:
    # Use service name + random value for unique instance IDs
    instance-id: ${spring.application.name}:${random.value}

Consuming Services with Eureka and RestTemplate

Once client services are registered, other services can discover and communicate with them using their logical service names instead of fixed URLs. Spring Cloud simplifies this with @LoadBalanced RestTemplate or WebClient.Builder. When you mark a RestTemplate bean with @LoadBalanced, Spring Cloud automatically intercepts calls, resolves the service name using Eureka, and applies client-side load balancing.

// Configuration class in calling service
@Configuration
public class AppConfig {

    @Bean
    @LoadBalanced
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

Now, in any component, you can inject this RestTemplate and call services by their spring.application.name.

// Service component calling 'my-service-client'
@Service
public class MyCallingService {

    private final RestTemplate restTemplate;

    public MyCallingService(@LoadBalanced RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public String callMyServiceClient() {
        // 'my-service-client' is the spring.application.name of the target service
        return restTemplate.getForObject("http://my-service-client/api/hello", String.class);
    }
}

For production, consider customizing the underlying HTTP client for your RestTemplate (e.g., Apache HttpClient) or WebClient (e.g., Reactor Netty) to fine-tune connection pooling, timeouts, and retry logic. Default settings can impact latency p99 and thread utilization, especially under heavy load. Properly configured connection pools are crucial for maintaining performance and resource efficiency across microservice calls.

Common Pitfalls

Forgetting @EnableEurekaServer or @EnableDiscoveryClient: This is a common oversight. Without these annotations, your application won't behave as a Eureka server or client.
Incorrect application.name: Other services locate your service using this name. Mismatches or typos prevent proper discovery.
Missing or Incorrect defaultZone: Ensure your client services point to the correct Eureka server URL in their configuration. A simple typo can make clients unable to register.
Firewall Issues: If Eureka server and client services are on different machines, make sure network firewalls allow communication on their respective ports (default 8761 for Eureka).
Default instance-id collision: When running multiple instances of the same service on the same host for local testing, Eureka needs unique instance-ids. Using ${spring.application.name}:${random.value} helps here.

Conclusion

You have now set up a basic, yet functional, service discovery mechanism using Spring Cloud Eureka. This pattern eliminates hardcoded URLs, simplifies scaling, and improves the overall resilience of your microservice architecture. By understanding the core components—the Eureka Server and its clients—and how to consume services, you are well-equipped to manage complex deployments. Next, explore client-side load balancing customization and resilience patterns like circuit breakers to make your microservices even more robust.

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Shubham Bhati — Sat, 01 Aug 2026 13:25:42 +0000

Published 2026-08-01 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Microservices architectures rely on services talking to each other, but hardcoding IP addresses or ports is a deployment, scaling and fault tolerance nightmare. When services scale out or crash, how do others find them? Service discovery solves this, letting services locate each other dynamically. This spring cloud eureka tutorial shows how to set up Spring Cloud Eureka for dynamic service registration and lookup. Ditch static configs and build resilient microservices.

1. Building Your Eureka Server

The Eureka Server acts as a central registry for all your microservices. It's the go-to place for services to register and discover each other. Setting one up with Spring Boot is simple: add the spring-cloud-starter-netflix-eureka-server dependency and enable it with an annotation.

For your pom.xml:

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
    </dependency>
</dependencies>
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

In your main application class:

package com.example.eurekaserver;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

Finally, configure your application.yml to prevent the server from registering itself and fetching registry information:

server:
  port: 8761 # Default Eureka server port
eureka:
  client:
    register-with-eureka: false
    fetch-registry: false

Production Note: For high availability, run multiple Eureka server instances that peer with each other. This ensures service discovery remains operational, crucial for low p99 latency on lookups.

2. Registering Services with Eureka Client

Client microservices need to register themselves with the Eureka server. This lets other services find product-service by its logical name.

To make a Spring Boot application a Eureka client, add the spring-cloud-starter-netflix-eureka-client dependency:

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>
</dependencies>
<!-- Dependency management section for Spring Cloud as before -->

Annotate your main application class with @EnableEurekaClient (often optional, but improves clarity).

package com.example.productservice;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableEurekaClient;

@SpringBootApplication
@EnableEurekaClient
public class ProductServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(ProductServiceApplication.class, args);
    }
}

Configure application.yml to point to the Eureka server and define the service's name:

spring:
  application:
    name: product-service
server:
  port: 8081 # Unique port for your service
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka

When product-service starts, it registers with the Eureka server. Check http://localhost:8761 to see product-service registered.

Production Note: Be mindful of client health checks. Eureka clients send heartbeats. If a client stops responding, Eureka will eventually de-register it. Ensure services have proper health endpoints and graceful shutdowns to prevent stale registrations. HikariCP connection pools can be impacted if services suddenly drop without de-registering.

3. Consuming Services with Eureka and Load Balancing

How does order-service find and call product-service? Spring Cloud integrates with Eureka for client-side load balancing. Using @LoadBalanced RestTemplate, you call services by their logical name.

Ensure your consuming service (e.g., order-service) has the Eureka client dependency and config.

Next, configure a @LoadBalanced RestTemplate bean:

package com.example.orderservice;

import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestTemplate;

@Configuration
public class OrderServiceConfig {

    @Bean
    @LoadBalanced // Essential for client-side load balancing via Eureka
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

Now, in your service logic, inject this RestTemplate and use the service ID (product-service) directly in your URL:

package com.example.orderservice;

import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;
import org.springframework.beans.factory.annotation.Autowired;

@Service
public class OrderService {

    @Autowired
    private RestTemplate restTemplate;

    public String getProductDetails(String productId) {
        // Eureka automatically resolves 'product-service' to an available instance
        String productUrl = "http://product-service/products/" + productId;
        return restTemplate.getForObject(productUrl, String.class);
    }
}

Spring Cloud, backed by Eureka, automatically resolves http://product-service to a running instance and handles load balancing across multiple instances.

Production Note: While RestTemplate is shown, WebClient from Spring WebFlux is generally recommended for new projects due to its non-blocking nature, offering better resource utilization. Ensure proper timeouts are configured to prevent cascading failures.

Common Pitfalls

Eureka Server Downtime: If your Eureka server isn't highly available, new services can't register and existing clients can't refresh their registry. This halts discovery.
Stale Registrations: Clients fail to de-register (e.g., due to crashes), leading to Eureka holding "dead" instances. Clients might call non-existent services, causing errors. Tune Eureka's eviction policies and client heartbeats.
Caching Issues (Client-side): While good for performance, aggressive caching or slow refresh rates can delay clients seeing new or removed instances.
Network Partitioning (Split Brain): During network splits, Eureka servers can lose connection to each other and clients. Understand Eureka's "self-preservation mode" which prevents mass de-registration during network issues, but can sometimes hide real problems.

Conclusion

You've now built a foundational understanding of service discovery using Spring Cloud Eureka. We set up a Eureka server, registered a client service, and enabled dynamic, load-balanced communication between microservices. This setup is crucial for building scalable, resilient architectures where services can come and go without manual intervention. Adopt this pattern to simplify your deployments, improve fault tolerance, and focus on your application logic rather than hardcoded service addresses.

Shubham Bhati, Backend Engineer (Java 17, Spring Boot, Microservices)

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Shubham Bhati — Thu, 30 Jul 2026 14:07:18 +0000

Published 2026-07-30 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

Hey there, backend engineers! Shubham Bhati here.

Remember the dread of hardcoding service URLs in your microservices? Hardcoding meant every scale-up, every IP change, and every deployment required manual configuration updates across multiple services – a recipe for downtime and operational headaches. This approach quickly becomes unmanageable as your architecture grows. That's where Service Discovery shines, allowing services to find each other dynamically. Let's get hands-on with a spring cloud eureka tutorial to wire up this essential microservices registry.

Setting Up Your Central Eureka Server

The Eureka Server acts as the central registry where all your microservices register themselves. It keeps track of service instances, their locations, and their health status. Setting one up is straightforward. You'll create a standard Spring Boot application and enable Eureka functionality.

// EurekaServerApplication.java
package com.example.eurekaserver;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer // This annotation turns your Spring Boot app into a Eureka Server
public class EurekaServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

Now, configure its properties. We tell it not to register itself and disable fetching registries since it is the registry.

# application.yml for Eureka Server
server:
  port: 8761 # Default port for Eureka Server

eureka:
  instance:
    hostname: localhost
  client:
    register-with-eureka: false # Don't register the Eureka Server itself
    fetch-registry: false      # Don't fetch a registry from itself
    service-url:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

Production Note: While simple, a single Eureka server is a Single Point of Failure (SPOF). For production, consider running multiple instances for high availability, perhaps behind a load balancer. Keep an eye on its memory footprint; as your microservices grow, the registry size increases. Also, think about thread pooling if you expect very high client registration/deregistration rates.

Registering Your Microservice with Eureka

Once your Eureka Server is up, your individual microservices need to register themselves. This makes them discoverable by other services.

First, add the Spring Cloud Eureka Client dependency to your pom.xml:

<!-- pom.xml snippet for client service -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

Then, enable discovery in your application and configure it to point to your Eureka Server.

// MyServiceClientApplication.java
package com.example.myserviceclient;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient; // Enables client discovery

@SpringBootApplication
@EnableDiscoveryClient
public class MyServiceClientApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyServiceClientApplication.class, args);
    }
}

And its configuration:

# application.yml for My Service Client
spring:
  application:
    name: my-service # Unique name for your service, used for discovery

server:
  port: 8080 # Example port for your client service

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/ # Point to your Eureka Server
  instance:
    hostname: localhost
    prefer-ip-address: true # Use IP address for registration

Production Note: Eureka clients send heartbeats to the server to maintain their registration. Misconfigured eureka.client.lease-renewal-interval-in-seconds can lead to stale entries or premature eviction. For critical services, monitor registration status and ensure spring.application.name is unique and meaningful across your entire microservices architecture. Also, be aware of firewall rules; ensure your client services can reach the Eureka server's port.

Discovering and Consuming Services

With services registered, now how does one service find and call another? Spring Cloud simplifies this by integrating client-side load balancing and discovery.

You can inject Spring's DiscoveryClient directly, but a more common and convenient way is to use RestTemplate (or WebClient) with @LoadBalanced.

// Some other consuming service
package com.example.consumer;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;
import org.springframework.cloud.client.loadbalancer.LoadBalanced;

@SpringBootApplication
@EnableDiscoveryClient
public class ConsumerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }

    @Bean
    @LoadBalanced // Essential for client-side load balancing
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

Now, in any component, you can use the RestTemplate to call my-service by its registered name:

// In a service class within ConsumerApplication
package com.example.consumer.service;

import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;

@Service
public class MyConsumerService {

    private final RestTemplate restTemplate;

    public MyConsumerService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public String callMyService() {
        // Use the service name directly! RestTemplate resolves it via Eureka.
        return restTemplate.getForObject("http://my-service/api/data", String.class);
    }
}

Production Note: Spring Cloud integrates client-side load balancing, crucial for distributing requests across multiple instances of a service and improving fault tolerance. This is automatically handled by the @LoadBalanced annotation. For very high-throughput scenarios, consider caching frequently accessed service instances locally to reduce repeated discovery calls, but be mindful of TTLs to avoid stale data. Monitor your network latency (p99) to ensure discovery isn't adding significant overhead.

Common Pitfalls to Avoid

Single Point of Failure for Eureka Server: Not deploying multiple Eureka instances. A single server means if it goes down, new service registrations fail and existing services can't update their status, eventually leading to stale information.
Misconfigured Client Heartbeats: Services either disappear from the registry too quickly or remain registered long after crashing. Tune lease-renewal-interval-in-seconds and lease-expiration-duration-in-seconds based on your service's health check frequency.
Ignoring spring.application.name: Not setting this property properly, or using non-unique names, leads to confusion and makes service lookup impossible or unreliable. It's the primary identifier for discovery.
Firewall Issues: Eureka server and client ports aren't open between different machines or within your containerized environment, preventing registration and discovery.
Not Using @LoadBalanced: Forgetting this annotation on your RestTemplate or WebClient.Builder means you won't get client-side load balancing, and direct service names won't resolve.

Conclusion

You've successfully wired up a powerful service discovery mechanism using Spring Cloud and Eureka. This foundational piece lets your microservices find each other dynamically, making your architecture scalable, resilient and much easier to manage. Keep building, innovating and deploying with confidence!

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Shubham Bhati — Wed, 29 Jul 2026 14:14:26 +0000

Published 2026-07-29 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

By Shubham Bhati, Backend Engineer (Java 17, Spring Boot, Microservices)

Imagine your microservices architecture growing from a handful to dozens. How do these services find each other? Hardcoding IP addresses is fragile. Manually updating DNS records for every new deployment is a maintenance nightmare, especially when dealing with scaling instances or failures. That's a production problem begging for a robust solution. This is where service discovery shines. In this spring cloud eureka tutorial, we'll cut through the complexity and get our microservices registered, discovered and communicating using Spring Cloud Netflix Eureka. Let's make our services intelligent enough to find their friends.

Setting Up Your Eureka Server

The Eureka Server acts as a centralized registry where all your microservices register themselves. It's the brain of your service discovery setup. When other services need to find an instance of a particular service, they query the Eureka Server. Running this server usually means dedicating a small VM or container. For production, consider at least two instances for high availability. While memory footprint is typically low for just the server, monitor its network I/O and CPU as client registrations scale.

First, create a new Spring Boot project and add the spring-cloud-starter-netflix-eureka-server dependency.

<!-- pom.xml -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

Next, enable the Eureka server in your main application class:

// EurekaServerApplication.java
package com.example.eurekaserver;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

Finally, configure your application.yml to disable client registration for the server itself and specify the port.

# application.yml for Eureka Server
server:
  port: 8761

eureka:
  client:
    register-with-eureka: false # Eureka Server doesn't register itself
    fetch-registry: false       # Eureka Server doesn't fetch registry from itself
  server:
    wait-time-in-ms-for-sync: 0 # Faster startup in dev, adjust for prod

Registering Your Microservice with Eureka Client

Now that our Eureka Server is ready, let's get a microservice to register itself. This service, often called a Eureka client, will periodically send heartbeats to the server, informing it of its availability. For a production service, ensure consistent spring.application.name values across all instances of a service. Health check configurations are crucial; a slow or failing health check could cause Eureka to prematurely de-register an otherwise healthy service, affecting p99 latency for upstream calls. Consider custom health indicators for deep service health rather than just basic HTTP checks.

First, add the spring-cloud-starter-netflix-eureka-client dependency to your microservice's pom.xml.

<!-- pom.xml for Microservice -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

Enable the discovery client in your microservice's main application class:

// MyServiceApplication.java
package com.example.myservice;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;

@SpringBootApplication
@EnableDiscoveryClient
public class MyServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyServiceApplication.class, args);
    }
}

Configure your microservice's application.yml with its name and the Eureka server URL:

# application.yml for Microservice
server:
  port: 8080 # or any other port

spring:
  application:
    name: my-first-service # This name is key for discovery

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka # Point to your Eureka Server

Consuming Services via DiscoveryClient and Load Balancing

With services registered, the next step is calling them. We don't want to use hardcoded IPs anymore. Spring Cloud provides DiscoveryClient and LoadBalancerClient (which RestTemplate with @LoadBalanced uses) to fetch service instances and distribute requests. When using RestTemplate with @LoadBalanced, a proxy intervenes to resolve service names to actual instances and handle client-side load balancing. For optimal production performance, consider configuring HikariCP connection pooling for your RestTemplate or WebClient beans to reduce connection overhead and latency, especially during high request volumes.

Here's how you can inject DiscoveryClient to manually find services:

// SomeServiceConsumer.java
package com.example.consumerservice;

import org.springframework.cloud.client.discovery.DiscoveryClient;
import org.springframework.stereotype.Service;
import java.util.List;

@Service
public class SomeServiceConsumer {

    private final DiscoveryClient discoveryClient;

    public SomeServiceConsumer(DiscoveryClient discoveryClient) {
        this.discoveryClient = discoveryClient;
    }

    public String callMyFirstService() {
        List<String> serviceUrls = discoveryClient.getInstances("my-first-service")
            .stream()
            .map(si -> si.getUri().toString())
            .toList(); // Java 17 .toList()

        // In a real scenario, you'd pick an instance and make an HTTP call
        if (!serviceUrls.isEmpty()) {
            return "Found 'my-first-service' at: " + serviceUrls.get(0);
        }
        return "Service 'my-first-service' not found.";
    }
}

For simpler HTTP calls with client-side load balancing, use @LoadBalanced on your RestTemplate or WebClient bean:

// MyServiceConsumerApplication.java
package com.example.consumerservice;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;

@SpringBootApplication
@EnableDiscoveryClient
public class MyServiceConsumerApplication {

    public static void main(String[] args) {
        SpringApplication.run(MyServiceConsumerApplication.class, args);
    }

    @Bean
    @LoadBalanced // Essential for service name resolution
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

Then, you can use the RestTemplate like this:

// MyServiceClient.java
package com.example.consumerservice;

import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;

@Service
public class MyServiceClient {

    private final RestTemplate restTemplate;

    public MyServiceClient(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public String getGreetingFromMyFirstService() {
        // Use the service name instead of host:port
        return restTemplate.getForObject("http://my-first-service/greeting", String.class);
    }
}

Common Pitfalls

Firewall or Network Issues: Ensure your Eureka Server and clients can communicate on the configured ports. AWS Security Groups or Docker network configurations are common culprits.
Incorrect service-url: Mismatched defaultZone in client configuration pointing to the wrong Eureka Server address or port.
Missing @EnableDiscoveryClient / @EnableEurekaServer: Forget these annotations and your application won't behave as a client or server.
Misconfigured spring.application.name: Each microservice instance needs a consistent spring.application.name to be discovered correctly.
Eureka Server Self-Registration: Accidentally allowing the Eureka server to try registering with itself, leading to errors or warnings.

Conclusion

Service discovery with Spring Cloud Eureka provides a reliable, dynamic way for your microservices to find each other, addressing a critical challenge in distributed systems. We've walked through setting up a Eureka Server, registering client services and consuming them using intelligent client-side load balancing. By understanding these core concepts and keeping production concerns in mind, you're well-equipped to build more resilient and scalable microservice applications. Start integrating Eureka today and simplify your microservice communication!

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Shubham Bhati — Tue, 28 Jul 2026 14:11:41 +0000

Published 2026-07-28 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

Author: Shubham Bhati, Backend Engineer (Java 17, Spring Boot, Microservices)

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Imagine your microservices architecture growing from a few services to dozens. Suddenly, hardcoding IP addresses or managing host files becomes a nightmare. Services go down, scale up or down dynamically, and your configuration files are constantly out of sync. This chaos directly impacts uptime and developer productivity. This is where service discovery becomes critical, and Spring Cloud Eureka offers a battle-tested solution. In this spring cloud eureka tutorial, we'll walk through setting up a Eureka server and client services to bring order to your distributed applications. Say goodbye to manual IP management and hello to dynamic service registration.

1. Setting Up the Eureka Server

The Eureka server acts as the central registry for your microservices. Services register themselves here and can discover other registered services. To start, create a new Spring Boot project. Add the Spring Cloud Eureka Server dependency to your pom.xml:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

In your main application class, simply annotate it with @EnableEurekaServer:

package com.example.eurekaserver;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

Configure your application.yml to specify the server port and tell Eureka not to register itself or fetch registry information (it's the server, after all):

server:
  port: 8761 # Default Eureka server port

eureka:
  client:
    register-with-eureka: false # Server doesn't register itself
    fetch-registry: false       # Server doesn't fetch registry info
  instance:
    hostname: localhost

Production Note: For high availability, you should run multiple Eureka server instances. They will peer with each other to synchronize registry data. This setup guards against a single point of failure. Also, monitor its memory footprint, especially in large deployments with many services frequently registering or renewing leases; it can become significant.

2. Registering Client Services

Now, let's register a microservice with our Eureka server. Create another Spring Boot project (e.g., product-service). Add the Spring Cloud Eureka Client dependency:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

In your main application class, annotate it with @EnableDiscoveryClient:

package com.example.productservice;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;

@SpringBootApplication
@EnableDiscoveryClient
public class ProductServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(ProductServiceApplication.class, args);
    }
}

Crucially, configure your client's application.yml to specify its name and the Eureka server's URL:

spring:
  application:
    name: product-service # This name is how other services find it

server:
  port: 8081

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka # Point to your Eureka server

When product-service starts, it will register itself with the Eureka server running on 8761. You can verify this by visiting http://localhost:8761 in your browser. This dynamic registration is a cornerstone of scalable microservices, ensuring your service registry is always up-to-date with active instances.

3. Consuming Registered Services

With services registered, the next step is discovering and calling them. Spring Cloud makes this straightforward. In another client service (e.g., order-service), add the Eureka client dependency and configure it as shown in Section 2.

You can use DiscoveryClient to programmatically fetch service instances:

package com.example.orderservice;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.cloud.client.ServiceInstance;
import org.springframework.cloud.client.discovery.DiscoveryClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.List;

@RestController
public class OrderController {

    @Autowired
    private DiscoveryClient discoveryClient;

    @GetMapping("/products-info")
    public String getProductsInfo() {
        List<ServiceInstance> instances = discoveryClient.getInstances("product-service");
        if (instances != null && !instances.isEmpty()) {
            ServiceInstance serviceInstance = instances.get(0); // Basic load balancing
            String baseUrl = serviceInstance.getUri().toString();
            // In a real scenario, use a RestTemplate or WebClient to call the service
            return "Found product-service at: " + baseUrl;
        }
        return "product-service not found!";
    }
}

A more common and powerful approach is to use RestTemplate with the @LoadBalanced annotation. This automatically integrates with Ribbon (Spring Cloud Netflix's client-side load balancer) to resolve service names to actual instances:

import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestTemplate;

@Configuration
public class AppConfig {
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

Then, you can inject and use it directly with the service name:

// Inside OrderController or another service class
@Autowired
private RestTemplate restTemplate;

@GetMapping("/call-product-service")
public String callProductService() {
    // Ribbon automatically intercepts "product-service" and replaces it with an actual instance URL
    return restTemplate.getForObject("http://product-service/api/products", String.class);
}

Production Note: While @LoadBalanced RestTemplate simplifies service calls, consider adding circuit breakers (like Resilience4j or a custom retry mechanism) to your client services. This prevents cascading failures if a downstream service is slow or unavailable, improving the p99 latency of your entire system.

Common Pitfalls

Eureka Server Downtime: If your single Eureka server goes down, clients can't register or discover new services. Always deploy multiple Eureka instances for high availability.
Incorrect Service Names: Misspelling the spring.application.name in client application.yml or the name used in DiscoveryClient/RestTemplate calls prevents discovery. Names must match exactly.
Firewall Issues: Ensure network firewalls aren't blocking communication between your client services and the Eureka server, or between services themselves.
Caching Stale Data: Eureka clients cache service registry information. If a service goes down or changes frequently, clients might hold stale data briefly. Ensure eureka.client.registry-fetch-interval-seconds is appropriately configured for your use case, though the default (30s) is usually fine.

Conclusion

Eureka and Spring Cloud simplify the complex task of service discovery in microservices architectures. By following this spring cloud eureka tutorial, you've learned to set up a centralized registry, register your microservices, and enable them to find and communicate with each other dynamically. This setup dramatically improves the scalability, resilience, and maintainability of your applications, allowing you to focus on business logic rather than infrastructure concerns. Implement these patterns to build more robust and flexible distributed systems.

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Shubham Bhati — Mon, 27 Jul 2026 14:40:03 +0000

Published 2026-07-27 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Remember the early days of microservices, trying to connect service-A to service-B? You’d hardcode URLs like http://localhost:8081/api/users, which quickly breaks down in production. What happens when service-B scales to multiple instances, or moves to a different IP address? You're in for a world of manual configuration headaches and deployment nightmares. This is where service discovery becomes essential. It’s the mechanism that allows microservices to find each other dynamically. Let's get hands-on with a spring cloud eureka tutorial to wire up dynamic service discovery in your microservices registry using Spring Cloud.

Setting Up Your Eureka Server

First, we need a central registry where all our services can register themselves. This is our Eureka Server. Create a new Spring Boot project and add the spring-cloud-starter-netflix-eureka-server dependency.

<!-- pom.xml for Eureka Server -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

Next, enable the Eureka server by annotating your main application class:

// EurekaServerApplication.java
package com.shubhambhati.eurekaserver;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

Configure your application.yml to set the server port and disable self-registration, as this server is the registry itself:

# application.yml for Eureka Server
server:
  port: 8761 # Default Eureka port

eureka:
  client:
    register-with-eureka: false # Server does not register itself
    fetch-registry: false       # Server does not fetch registry from itself
  server:
    wait-time-in-ms-for-sync-on-startup: 5000 # Give clients time to register
    enable-self-preservation: false # Disable for development, keep enabled for prod

Production Note: For high availability, always run multiple Eureka Server instances, typically a cluster of three. Each server should point to its peers in its serviceUrl.defaultZone configuration. Disabling enable-self-preservation in production could lead to services being prematurely de-registered during network partitions or temporary slowdowns, so enable it carefully. Monitor Eureka's memory footprint; while typically small, a large number of instances can increase it.

Registering Microservices with Eureka Client

Now, let's make our microservices discoverable. For each service you want to register (e.g., a user-service or product-service), add the spring-cloud-starter-netflix-eureka-client dependency.

<!-- pom.xml for Microservice Client -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Enable the discovery client in your service's main application class:

// UserServiceApplication.java
package com.shubhambhati.userservice;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;

@SpringBootApplication
@EnableDiscoveryClient
public class UserServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserServiceApplication.class, args);
    }
}

Configure your application.yml for the service to point to the Eureka Server and define its unique name:

# application.yml for UserService
server:
  port: 8080

spring:
  application:
    name: user-service # This name will be used for discovery

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka # Point to your Eureka Server
  instance:
    instance-id: ${spring.application.name}:${random.value} # Unique ID for multiple instances
    lease-renewal-interval-in-seconds: 5 # How often client sends heartbeats
    lease-expiration-duration-in-seconds: 10 # How long server waits without heartbeat

Production Note: The instance-id is crucial when running multiple instances of the same service on the same host or for distinguishing them in the Eureka dashboard. It ensures each instance registers uniquely. Eureka operates on eventual consistency; it takes a short period for changes (like a service registering or de-registering) to propagate. Account for this latency in your system design. Also, ensure your application's health checks are integrated; if a service is unhealthy, Eureka might still show it as available unless configured with Spring Boot Actuator for health monitoring.

Consuming Services with Spring Cloud LoadBalancer

Once your services are registered, others need to find and call them using their service ID instead of hardcoded IPs. Spring Cloud provides LoadBalancerClient and integrates with RestTemplate or WebClient to abstract this process. Add spring-cloud-starter-loadbalancer to your consuming service.

<!-- pom.xml for Consuming Service -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-loadbalancer</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId> <!-- Or spring-boot-starter-web for RestTemplate -->
</dependency>

You can then create a WebClient or RestTemplate bean and use the service ID directly in the URL:

// In your consuming service configuration
package com.shubhambhati.orderservice;

import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.reactive.function.client.WebClient;

@Configuration
public class WebClientConfig {

    @Bean
    @LoadBalanced // Essential for using service names in URLs
    public WebClient.Builder loadBalancedWebClientBuilder() {
        return WebClient.builder();
    }
}

Now, inject WebClient.Builder and build your WebClient instances:

// In a service class that calls UserService
package com.shubhambhati.orderservice;

import org.springframework.stereotype.Service;
import org.springframework.web.reactive.function.client.WebClient;
import reactor.core.publisher.Mono;

@Service
public class OrderService {

    private final WebClient webClient;

    public OrderService(WebClient.Builder webClientBuilder) {
        this.webClient = webClientBuilder.baseUrl("lb://USER-SERVICE").build(); // "USER-SERVICE" is the registered name
    }

    public Mono<String> getUserDetails(Long userId) {
        return webClient.get()
                .uri("/users/{id}", userId)
                .retrieve()
                .bodyToMono(String.class); // Assuming user details are a String for simplicity
    }
}

Production Note: The @LoadBalanced annotation is key here; it tells Spring Cloud to intercept calls to URLs starting with lb:// and resolve them using the LoadBalancerClient. Always implement circuit breakers (like Resilience4j or Hystrix) around inter-service calls to prevent cascading failures. Monitor p99 latency for these calls; if it spikes, it often indicates an upstream service issue or network bottleneck. Proper timeouts for WebClient or RestTemplate are critical to prevent resource exhaustion.

Common Pitfalls

Single Point of Failure for Eureka Server: Running only one Eureka server in production leaves you vulnerable if it goes down. Always deploy a cluster (e.g., 3 instances) for high availability.
Misconfigured defaultZone: Clients must correctly point to the Eureka server's serviceUrl.defaultZone. A typo or wrong port means your services won't register.
Ignoring Service Health Checks: If a service registers but isn't healthy (e.g., database connection issues), Eureka will still advertise it. Integrate Spring Boot Actuator health endpoints (management.endpoint.health.show-details: always) and configure Eureka to use them for more accurate client-side load balancing.
Lack of Circuit Breakers and Retries: Relying purely on service discovery without resilience patterns like circuit breakers (Resilience4j) or retry mechanisms will lead to cascading failures when a downstream service experiences issues.

Conclusion

Service discovery with Eureka and Spring Cloud dramatically simplifies managing microservices deployments. It frees you from hardcoding network locations, allowing your applications to scale and adapt dynamically. By following this guide, you can quickly set up your Eureka server, register your services, and enable dynamic service consumption, bringing much-needed agility to your microservice architecture. Embrace service discovery to build more resilient and scalable systems.

MySQL Transactions and Isolation Levels: A Backend Engineer's Guide

Shubham Bhati — Sun, 26 Jul 2026 13:27:04 +0000

Published 2026-07-26 by Shubham Bhati — Backend Engineer (Java 17, Spring Boot, Microservices).

MySQL Transactions and Isolation Levels: A Backend Engineer's Guide

Hey everyone, Shubham Bhati here. Ever stared blankly at logs after a report showed inconsistent data, or worse, found money missing from an account despite your code looking perfectly fine? It's a frustrating spot. Oftentimes, these elusive bugs are not application logic errors but stem from concurrent operations hitting your database in unexpected ways. Understanding MySQL transaction isolation levels isn't just academic; it's critical for building stable, predictable, and resilient backend systems. Let's dive into how to tame these concurrency beasts and ensure your data integrity, even under heavy load.

The Foundation: Transactions and ACID Properties

At its core, a transaction is a single, logical unit of work that either completes entirely or fails completely. Think of a bank transfer: debiting one account and crediting another must happen as one operation. If one part fails, the whole thing should roll back. This concept is underpinned by ACID properties: Atomicity (all or nothing), Consistency (data remains valid), Isolation (concurrent transactions don't interfere), and Durability (once committed, changes are permanent).

In Spring Boot, we manage transactions declaratively using the @Transactional annotation. This powerful annotation wraps your method execution in a database transaction, automatically handling commits and rollbacks based on exceptions. It's convenient, but don't let its simplicity mask the complexities beneath.

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class AccountService {

    private final AccountRepository accountRepository;

    public AccountService(AccountRepository accountRepository) {
        this.accountRepository = accountRepository;
    }

    @Transactional
    public void transferMoney(Long fromAccountId, Long toAccountId, double amount) {
        Account fromAccount = accountRepository.findById(fromAccountId)
                                .orElseThrow(() -> new IllegalArgumentException("Sender not found"));
        Account toAccount = accountRepository.findById(toAccountId)
                                .orElseThrow(() -> new IllegalArgumentException("Recipient not found"));

        if (fromAccount.getBalance() < amount) {
            throw new IllegalArgumentException("Insufficient funds");
        }

        fromAccount.setBalance(fromAccount.getBalance() - amount);
        toAccount.setBalance(toAccount.getBalance() + amount);

        accountRepository.save(fromAccount);
        accountRepository.save(toAccount);
        // If an exception occurs here, both saves will be rolled back.
    }
}

Production Note: When a method annotated with @Transactional is called, HikariCP (your connection pool) provides a database connection from its pool. This connection is then exclusively held by the transaction until it commits or rolls back. This means a long-running transaction can tie up a connection, potentially starving other requests and impacting overall application throughput. Keep transactions short and focused.

Demystifying Isolation Levels

Isolation is the "I" in ACID, dictating how operations in one transaction are visible to others. SQL defines four standard isolation levels, each preventing a different set of concurrency anomalies, with increasing strictness:

READ UNCOMMITTED: Least strict. Transactions can see uncommitted changes made by other transactions (Dirty Reads). Rarely used in production due to severe data integrity risks.
READ COMMITTED: Prevents Dirty Reads. Transactions only see changes that have been committed. However, a transaction might read different values for the same row if another transaction commits changes between reads (Non-Repeatable Reads).
REPEATABLE READ: Prevents Dirty Reads and Non-Repeatable Reads. If you read a row multiple times within a transaction, you'll always get the same data. MySQL's default isolation level for InnoDB tables. It still allows for Phantom Reads, where new rows inserted by another committed transaction might appear in subsequent queries within the same transaction.
SERIALIZABLE: Most strict. Prevents Dirty Reads, Non-Repeatable Reads, and Phantom Reads. Transactions execute as if they were run sequentially. This level provides maximum data integrity but comes with significant performance overhead due to extensive locking.

MySQL's default REPEATABLE READ is often a good balance for many applications. It uses MVCC (Multi-Version Concurrency Control) for reads to avoid blocking, but uses gap and next-key locks to prevent phantom reads for specific ranges, sometimes making it behave closer to SERIALIZABLE in certain scenarios.

import org.springframework.transaction.annotation.Isolation;

// ... inside a Spring @Service class
@Transactional(isolation = Isolation.READ_COMMITTED)
public Order processOrder(String orderId) {
    // This transaction will only see committed data.
    // However, if we read customer balance here, then later read it again,
    // and another transaction updates it in between, we might see different balances.
    Order order = orderRepository.findById(orderId)
                        .orElseThrow(() -> new OrderNotFoundException(orderId));
    // Perform processing...
    return orderRepository.save(order);
}

Production Note: Choosing an isolation level is a trade-off between data consistency and concurrency performance. Stricter levels (like SERIALIZABLE) mean more locks, which can lead to higher latency (p99) and increased chances of deadlocks, especially under high concurrent load. Less strict levels increase throughput but risk data anomalies. Measure and test your choices under realistic load.

When to Adjust Isolation Levels (and Why)

While REPEATABLE READ is MySQL's default, there are specific scenarios where you might consider adjusting it. For instance, if you have a dashboard reporting system that needs to display the absolute latest committed data without being concerned about "non-repeatable reads" within a single transaction, READ COMMITTED might offer slightly better concurrency. This is because READ COMMITTED releases read locks earlier, allowing other transactions to write to the same rows sooner.

Consider a system generating daily summary reports. If the report pulls data throughout the day and needs to reflect all committed changes up to the moment of each individual query, even if it means seeing different intermediate totals, READ COMMITTED could be appropriate.

import org.springframework.transaction.annotation.Isolation;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class ReportService {

    private final SalesRepository salesRepository;
    private final InventoryRepository inventoryRepository;

    public ReportService(SalesRepository salesRepository, InventoryRepository inventoryRepository) {
        this.salesRepository = salesRepository;
        this.inventoryRepository = inventoryRepository;
    }

    // This method needs to read the latest committed data for summary.
    // We accept potential non-repeatable reads for different sub-queries
    // in favor of higher concurrency for the underlying tables.
    @Transactional(isolation = Isolation.READ_COMMITTED, readOnly = true)
    public DailySummary generateDailySummary() {
        long totalSales = salesRepository.countAllSalesToday();
        long currentInventory = inventoryRepository.countAllItemsInStock();
        // Even if inventory changes between these two queries,
        // we're fine with capturing the latest state at each query point.
        return new DailySummary(totalSales, currentInventory);
    }
}

Using SERIALIZABLE is generally discouraged unless absolute, bulletproof consistency is paramount (e.g., highly sensitive financial ledger updates where even phantom reads are unacceptable) and you can tolerate the significant performance hit. It applies range locks, which can drastically reduce concurrency. Always opt for the least strict isolation level that meets your application's consistency requirements.

Common Pitfalls

Ignoring MySQL's Default: Assuming your database's isolation level is what you configured in your application.properties without verifying. MySQL's default REPEATABLE READ often surprises developers expecting READ COMMITTED (like PostgreSQL's default).
Overusing SERIALIZABLE: While it offers maximum safety, the performance cost is often too high for most web applications. Extensive locking leads to slow response times and increased deadlocks.
Not Testing Concurrency Locally: Many concurrency issues only manifest under heavy load. Test your services with multiple concurrent users to identify potential data anomalies or deadlocks.
Misunderstanding Read Phenomena: Not knowing the difference between Dirty Reads, Non-Repeatable Reads, and Phantom Reads makes it impossible to correctly choose an isolation level. Invest time in understanding these concepts.

Conclusion

Mastering MySQL transactions and their isolation levels is fundamental for any backend engineer working with relational databases. It's about more than just slapping @Transactional on a method; it's about making informed decisions on data consistency versus performance. Understand your data's integrity requirements, choose the appropriate isolation level, and always test your assumptions under load. Your users and your future self debugging production issues will thank you.

DEV Community: Shubham Bhati

Asynchronous Programming in Spring Boot with CompletableFuture

Turbocharge Your Spring Boot APIs: Mastering Asynchronous Programming with CompletableFuture

The Bottleneck: Synchronous Spring Boot APIs

Embracing Asynchronicity with @Async and CompletableFuture

Fine-Tuning Asynchronous Execution: Custom Thread Pools

Common Pitfalls

Conclusion

Further Reading

Asynchronous Programming in Spring Boot with CompletableFuture

Asynchronous Programming in Spring Boot with CompletableFuture

Unleashing @async: The Foundation

Configuring a Custom Thread Pool

Mastering CompletableFuture for Orchestration

Common Pitfalls

Conclusion

Further Reading

Asynchronous Programming in Spring Boot with CompletableFuture

Asynchronous Programming in Spring Boot with CompletableFuture

Getting Started with @Async

Customizing Your Async Thread Pool

Mastering CompletableFuture for Complex Flows

Common Pitfalls

Conclusion

Further Reading

Asynchronous Programming in Spring Boot with CompletableFuture

Supercharge Your Spring Boot Apps: Mastering Asynchronous Operations with CompletableFuture

Kickstarting Asynchronicity with @Async

Custom Thread Pools: The Foundation of Control

CompletableFuture: Unleashing True Asynchronicity

Common Pitfalls

Conclusion

Further Reading

Asynchronous Programming in Spring Boot with CompletableFuture

Mastering Asynchronous Programming in Spring Boot with CompletableFuture

Enabling Asynchronous Execution

Configuring a Custom Thread Pool

Composing Asynchronous Operations with CompletableFuture

Common Pitfalls

Conclusion

Further Reading

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Setting Up Your Eureka Server

Registering a Client Service

Consuming Services with Eureka and RestTemplate

Common Pitfalls

Conclusion

Further Reading

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

1. Building Your Eureka Server

2. Registering Services with Eureka Client

3. Consuming Services with Eureka and Load Balancing

Common Pitfalls

Conclusion

Further Reading

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Setting Up Your Central Eureka Server

Registering Your Microservice with Eureka

Discovering and Consuming Services

Common Pitfalls to Avoid

Conclusion

Further Reading

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

By Shubham Bhati, Backend Engineer (Java 17, Spring Boot, Microservices)

Setting Up Your Eureka Server

Registering Your Microservice with Eureka Client

Consuming Services via DiscoveryClient and Load Balancing

Common Pitfalls

Conclusion

Further Reading

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

Service Discovery with Eureka and Spring Cloud: A Hands-On Tutorial

1. Setting Up the Eureka Server

2. Registering Client Services

3. Consuming Registered Services

Common Pitfalls

Conclusion

Embracing Asynchronicity with `@Async` and `CompletableFuture`

Getting Started with `@Async`

Mastering `CompletableFuture` for Complex Flows

Kickstarting Asynchronicity with `@Async`

`CompletableFuture`: Unleashing True Asynchronicity