How does @Async work in Spring, and what are its pitfalls?

@Async, combined with @EnableAsync, tells Spring to execute an annotated method on a separate thread from a configured task executor, returning immediately (optionally with a Future/CompletableFuture the caller can use to get the eventual result) instead of blocking the calling thread. Pitfalls: like @Transactional, it's implemented via an AOP proxy, so self-invocation from within the same class silently doesn't run asynchronously; exceptions thrown inside a void-returning @Async method are simply lost unless a custom AsyncUncaughtExceptionHandler is configured; and without an explicitly configured executor, Spring falls back to a default SimpleAsyncTaskExecutor that creates a new thread per call with no pooling or bound, which can exhaust resources under load.

How does @Scheduled work, and what are its limitations in a multi-instance deployment?

@Scheduled, combined with @EnableScheduling, runs an annotated method automatically on a fixed schedule — via a fixed rate, a fixed delay, or a cron expression — using a task scheduler managed by Spring, with no external scheduling infrastructure needed for a single instance. Its major limitation: if the application is deployed as multiple instances (for scaling or high availability), every instance runs the same @Scheduled method independently and simultaneously by default, which is usually wrong for tasks that should run exactly once across the whole fleet — requiring an external coordination mechanism (a distributed lock via ShedLock, or delegating scheduling to an external, single-writer system) to avoid duplicate execution.

How do Spring application events (@EventListener, ApplicationEventPublisher) support decoupled, in-process communication?

Covered in depth under Spring Core, but worth restating in a messaging context: application events are Spring's in-process, synchronous-by-default publish-subscribe mechanism, useful for decoupling side effects within a single application instance without needing an external message broker at all. They're the right tool when the producer and consumer(s) of an event live in the same JVM/deployment; once that communication needs to cross process or service boundaries, a real message broker (Kafka, RabbitMQ) becomes necessary instead.

How do you integrate Spring Boot with Kafka (@KafkaListener, KafkaTemplate)?

spring-kafka provides KafkaTemplate for producing messages to a topic and @KafkaListener for consuming them, both configured via standard application.yml properties (bootstrap servers, consumer group ID, serializers/deserializers) rather than manual Kafka client boilerplate. A producer calls kafkaTemplate.send(topic, key, value) to publish a message (with the option to handle the resulting ListenableFuture/CompletableFuture for delivery confirmation), while a consumer method annotated @KafkaListener(topics = "...", groupId = "...") is invoked automatically by the framework whenever a new message arrives on that topic for its consumer group.

How do you integrate Spring Boot with RabbitMQ (@RabbitListener, RabbitTemplate)?

spring-amqp/spring-rabbit provides RabbitTemplate for sending messages to an exchange (with a routing key) and @RabbitListener for consuming messages from a queue, configured declaratively via application.yml and simple @Bean definitions for exchanges/queues/bindings. Unlike Kafka's topic-and-consumer-group model, RabbitMQ's routing is built around exchanges (which decide how a published message gets routed) and queues (which actually hold messages for consumers) connected by bindings — giving flexible routing patterns (direct, topic, fanout) suited to more traditional task-queue and pub-sub messaging scenarios.

When should you choose synchronous processing vs asynchronous messaging in a Spring Boot application?

Choose synchronous processing when the caller genuinely needs an immediate result to proceed (validating input, checking availability before confirming to the user) and the operation is fast and reliable enough that blocking briefly is acceptable. Choose asynchronous messaging when the operation is a side effect that doesn't need to block the primary flow (sending a notification, updating an analytics system), when the work is slow or unreliable enough that the caller shouldn't wait on it directly, or when multiple independent consumers need to react to the same event without the producer needing to know about any of them.

Messaging, Async & Scheduling

Running work off the request thread, on a schedule, or via a message broker.

Difficulty

Open as page

@Async, combined with @EnableAsync on a configuration class, lets a method run on a separate thread, so the caller doesn't block waiting for it to complete:

@Configuration
@EnableAsync
class AsyncConfig { }

@Service
class NotificationService {
    @Async
    void sendWelcomeEmail(String email) {
        // runs on a separate thread — sendWelcomeEmail() returns to the caller immediately
    }

    @Async
    CompletableFuture<Boolean> sendWelcomeEmailWithResult(String email) {
        boolean sent = emailClient.send(email);
        return CompletableFuture.completedFuture(sent); // caller can .get()/.thenApply() on this
    }
}

Pitfalls to watch for:

Self-invocation bypasses the proxy — exactly like @Transactional. @Async is implemented via the same AOP proxy mechanism, so calling an @Async method on this, from within the same class, calls the real method directly and synchronously — the annotation is silently ignored:

@Service
class NotificationService {
    void processSignup(User user) {
        sendWelcomeEmail(user.getEmail()); // NOT async — bypasses the proxy, runs synchronously!
    }
    @Async
    void sendWelcomeEmail(String email) { ... }
}

Fix: move the @Async method to a separate bean.

Exceptions from a void-returning @Async method are silently lost by default — there's no caller waiting on a Future to propagate the exception back to. Configuring a custom AsyncUncaughtExceptionHandler (via AsyncConfigurer) is necessary to actually observe/log these failures, otherwise they vanish without a trace:

@Configuration
@EnableAsync
class AsyncConfig implements AsyncConfigurer {
    @Override
    public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
        return (ex, method, params) -> log.error("Async method {} threw", method, ex);
    }
}

Methods returning CompletableFuture/Future don't have this problem — the exception is captured in the future itself, retrievable via .get()/.exceptionally(...).

No custom executor configured → an unbounded, unpooled default. Without explicitly defining a TaskExecutor bean, Spring falls back to SimpleAsyncTaskExecutor, which creates a brand-new thread for every single invocation, with no pooling and no upper bound — under any real load, this can exhaust system resources quickly. Always configure an explicit, bounded ThreadPoolTaskExecutor:

@Bean(name = "taskExecutor")
Executor taskExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(5);
    executor.setMaxPoolSize(20);
    executor.setQueueCapacity(100);
    return executor;
}

Open as page

@Scheduled, combined with @EnableScheduling, lets a method run automatically on a defined schedule, without any external cron daemon or scheduling infrastructure — Spring manages the timing internally via a TaskScheduler:

@Configuration
@EnableScheduling
class SchedulingConfig { }

@Component
class ReportJob {
    @Scheduled(fixedRate = 60000)        // every 60 seconds, measured from start-to-start
    void runEveryMinute() { ... }

    @Scheduled(fixedDelay = 60000)       // 60 seconds after the *previous run finished*
    void runWithDelay() { ... }

    @Scheduled(cron = "0 0 2 * * *")     // cron expression — every day at 2:00 AM
    void runNightlyReport() { ... }
}

fixedRate measures the interval between successive start times (so if a run takes longer than the interval, the next one starts immediately after the previous finishes, rather than overlapping); fixedDelay measures the interval from one run's completion to the next run's start.

The major limitation: multi-instance deployments. @Scheduled has no built-in awareness of other instances of the same application running elsewhere. If the application is scaled horizontally to, say, 4 instances for availability/load reasons, all 4 instances will independently trigger the same @Scheduled method at the same scheduled time — which is almost never the intended behavior for a task that should logically run exactly once across the whole fleet (e.g., "generate today's single daily report," "send one batch of reminder emails," not four duplicate copies of each).

Common solutions:

A distributed lock library like ShedLock — wraps the scheduled method so that, across all instances, only whichever one acquires the lock first actually executes the method for that scheduled trigger; the others detect the lock is held and simply skip that run:

@Scheduled(cron = "0 0 2 * * *")
@SchedulerLock(name = "nightlyReport", lockAtMostFor = "PT30M")
void runNightlyReport() { ... }

Delegate scheduling to a single, external, dedicated trigger source (a Kubernetes CronJob that invokes exactly one instance/endpoint, an external workflow scheduler) instead of relying on @Scheduled running independently inside every replica of the application.
Restrict the scheduled logic to run only on a designated "leader" instance, using a leader-election mechanism — more complex to set up than ShedLock for most cases, but sometimes appropriate in systems that already have leader election available for other reasons.

Practical guidance: @Scheduled alone is fine for a single-instance deployment, or for scheduled work that's genuinely safe to run redundantly on every instance (e.g., refreshing an in-memory, per-instance cache) — but the moment a task must run exactly once across a horizontally-scaled fleet, @Scheduled by itself is the wrong tool without adding one of these coordination mechanisms on top.

Open as page

Spring's built-in application event mechanism (ApplicationEventPublisher.publishEvent() + @EventListener, detailed under Spring Core & DI) is worth specifically distinguishing from external messaging (Kafka/RabbitMQ), since both solve a "decouple the producer from the consumer" problem but at very different scopes.

Application events are in-process only — they exist entirely within a single JVM/application instance's ApplicationContext. A UserRegisteredEvent published in one instance is only visible to @EventListener methods registered in that same instance; a separate instance of the same application (in a horizontally-scaled deployment) never sees it at all.

@Service
class UserService {
    private final ApplicationEventPublisher publisher;
    void register(User user) {
        // ... save user ...
        publisher.publishEvent(new UserRegisteredEvent(user.getId())); // visible only within this JVM
    }
}

When application events are the right tool:

Decoupling side effects that only need to happen within the same application instance that triggered them — e.g., invalidating a local in-memory cache after an update, triggering a secondary in-process computation, or simply organizing code so unrelated concerns (sending a notification, writing an audit entry) aren't hard-wired directly into the primary operation's method body.
No additional infrastructure (a message broker, network reliability concerns, serialization format) is needed at all — it's essentially free, using plain in-memory method dispatch under the hood.

When you need real messaging (Kafka/RabbitMQ) instead:

The consumer needs to run in a different service or process entirely — application events never cross a JVM boundary, let alone a network boundary.
You need durability — if no instance is currently running (or the instance crashes right after publishing), an application event is simply lost forever, with no persistence or replay; a message broker persists messages until they're actually consumed (and acknowledged).
You need to scale consumers independently from producers, or have multiple different services (not just multiple listeners within one service) react to the same event.

Practical guidance: default to Spring application events for decoupling within a single service/instance — it's simpler, has zero extra infrastructure, and is easy to reason about; reach for an actual message broker only once the communication genuinely needs to cross process/service boundaries or requires durability guarantees an in-memory event can't provide.

Open as page

spring-kafka wraps the plain Apache Kafka Java client with Spring-friendly abstractions, removing most of the manual producer/consumer setup boilerplate.

Configuration (application.yml):

spring:
  kafka:
    bootstrap-servers: localhost:9092
    consumer:
      group-id: order-service-group
      auto-offset-reset: earliest
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.springframework.kafka.support.serializer.JsonDeserializer
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.springframework.kafka.support.serializer.JsonSerializer

Producing messages with KafkaTemplate:

@Service
class OrderEventPublisher {
    private final KafkaTemplate<String, OrderPlacedEvent> kafkaTemplate;

    OrderEventPublisher(KafkaTemplate<String, OrderPlacedEvent> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    void publish(OrderPlacedEvent event) {
        kafkaTemplate.send("order-events", event.orderId(), event)
            .whenComplete((result, ex) -> {
                if (ex != null) log.error("Failed to publish order event", ex);
            });
    }
}

Consuming messages with @KafkaListener:

@Component
class OrderEventConsumer {
    @KafkaListener(topics = "order-events", groupId = "inventory-service-group")
    void handleOrderPlaced(OrderPlacedEvent event) {
        inventoryService.reserveStock(event.orderId());
        // by default, the offset is committed automatically after this method returns successfully
    }
}

Key concepts worth understanding:

Consumer groups: multiple instances of the same service sharing the same groupId automatically divide up a topic's partitions among themselves — each message is delivered to only one consumer instance within a given group, which is what makes horizontal scaling of consumers work correctly (as opposed to every instance redundantly processing every message).
Serialization: producer and consumer must agree on serializer/deserializer pairs (JsonSerializer/JsonDeserializer being a common, simple default for structured messages) — a mismatch here is a common source of "consumer silently fails to deserialize" issues.
Delivery/processing guarantees: by default, spring-kafka commits consumer offsets automatically after a listener method returns without throwing — meaning careful thought is needed about idempotency (can this handler safely process the same message twice, since Kafka's at-least-once delivery model means redelivery is possible after certain failure scenarios) and error handling (a DefaultErrorHandler can be configured with retry/backoff and a dead-letter-topic strategy for messages that repeatedly fail processing).

When Kafka fits well: high-throughput event streaming, durable event logs multiple independent consumers can replay/process at their own pace, and scenarios where strict message ordering within a partition (e.g., all events for a given order ID) matters.

Related Resources

Spring for Apache Kafka

Open as page

spring-amqp/spring-rabbit provides Spring-friendly abstractions over RabbitMQ, following the AMQP model of exchanges, queues, and bindings rather than Kafka's partitioned-topic-and-consumer-group model.

Declaring the topology (exchange, queue, and the binding connecting them) as beans:

@Configuration
class RabbitConfig {
    @Bean
    Queue orderQueue() { return new Queue("order.queue", true); } // durable queue

    @Bean
    TopicExchange orderExchange() { return new TopicExchange("order.exchange"); }

    @Bean
    Binding binding(Queue orderQueue, TopicExchange orderExchange) {
        return BindingBuilder.bind(orderQueue).to(orderExchange).with("order.placed.*");
    }
}

Producing messages with RabbitTemplate:

@Service
class OrderEventPublisher {
    private final RabbitTemplate rabbitTemplate;

    void publish(OrderPlacedEvent event) {
        rabbitTemplate.convertAndSend("order.exchange", "order.placed.created", event);
        // exchange name, routing key, and the message payload (auto-converted, typically to/from JSON)
    }
}

Consuming messages with @RabbitListener:

@Component
class OrderEventConsumer {
    @RabbitListener(queues = "order.queue")
    void handleOrderPlaced(OrderPlacedEvent event) {
        inventoryService.reserveStock(event.orderId());
        // acknowledged automatically on successful return, by default
    }
}

Key conceptual difference from Kafka — routing via exchanges: RabbitMQ's exchange is the component that decides how an incoming published message gets routed to zero, one, or multiple queues, based on the exchange type and the message's routing key:

Direct exchange: routes to queues bound with an exact matching routing key.
Topic exchange: routes based on wildcard-pattern matching against the routing key (order.placed.* matching order.placed.created, order.placed.updated, etc.) — used in the example above.
Fanout exchange: routes a message to every queue bound to it, regardless of routing key — a simple broadcast/pub-sub pattern.

This gives RabbitMQ very flexible, fine-grained routing topologies, in contrast to Kafka's simpler (but very high-throughput, replay-capable) topic-and-partition model.

When RabbitMQ tends to fit well: traditional task-queue/work-distribution scenarios, complex routing requirements (multiple consumer types needing different subsets of messages based on routing patterns), and cases valuing RabbitMQ's mature per-message acknowledgment and flexible dead-lettering/retry semantics over Kafka's strengths in extremely high-throughput, replayable event-log style streaming.

Open as page

This decision comes up constantly when designing a new interaction between components (or services), and it's worth having a clear, repeatable framework rather than deciding case-by-case on gut feel alone.

Lean synchronous when:

The caller genuinely needs the result immediately to decide what to do next — e.g., "is this item in stock" needs an answer before the checkout flow can proceed to payment; there's no meaningful way to "eventually" tell the user whether their order succeeded after they've already left the page.
The operation is fast and reliable enough that blocking briefly is a reasonable cost — a well-tuned database query or a fast internal service call.
The interaction is fundamentally a question-and-answer, not a notification — "what is the current price of this item" is a query; "an order was placed" is an event.

Lean asynchronous (messaging) when:

The work is a side effect that doesn't need to block the primary operation's success — sending a confirmation email shouldn't hold up (or worse, fail) the actual order-placement transaction just because the email provider is briefly slow.
The work is slow, unreliable, or has unpredictable latency, and forcing the caller to wait on it directly would create a poor user experience or tie up resources unnecessarily — e.g., generating a large report, calling a flaky third-party API.
Multiple independent consumers need to react to the same event, and the producer shouldn't need to know about any of them, or be blocked by however many consumers happen to exist — publishing one OrderPlacedEvent that both an inventory service and an analytics service independently consume is far more decoupled than the order service directly, synchronously calling each one in turn.
You want resilience against a downstream outage — if the notification service is down, a message just waits in the broker's queue until it recovers, rather than the entire triggering operation failing outright.

A useful litmus test: ask "if this specific piece of work failed or was delayed by 30 seconds, would the user/caller actually notice or care right now?" If yes (e.g., "did my payment go through"), it likely belongs in the synchronous path. If no (e.g., "did the confirmation email get sent yet"), it's a strong candidate for asynchronous messaging.

In practice, most real systems use both for different parts of the same overall flow — a single "place order" user action might synchronously validate stock and charge a payment, while asynchronously triggering email confirmation, analytics, and downstream fulfillment notifications, each communication style chosen deliberately for what that specific piece of work actually needs.