Spring Boot Interview Question - Sending Email After User Registration
Sync, async, outbox, workers, concepts, code samples and more.
Scenario
You are implementing a user registration endpoint in a Spring Boot service.
Current implementation:
Current Problems:
As registration volume grows:
API response time increases
The thread pool gets blocked on email I/O
If email sending fails, the system state may become inconsistent
Hard to scale and retry safely
What is the problem with sending an email synchronously inside the registration flow?
Email sending is an I/O-bound, slow operation (SMTP calls, network delays, retries).
The registration request blocks until the email is sent
User waits longer for a response
P95 / P99 latency increases as traffic grows
API response time becomes dependent on the email provider’s performance.
As traffic increases:
Thread pools get exhausted
Throughput drops
The system becomes harder to scale horizontally
If DB commit succeeds, email fails, User exists but never receives welcome email
📢 Get actionable Java insights every week — from practical code tips to expert interview questions you can use today.
Join 3200+ subscribers and level up your Spring & backend skills with hand-crafted content — no fluff.
Some of you have reached out to my email for some discounts on an annual subscription. I understand that for recent graduates and students, it’s challenging to pay $30 per year. I would like to offer an additional 40% discount ($ 12 per year) until January 31st.
Not convinced? Check out the details of the past work
How would you redesign this flow? discuss some potential solutions.
1.Using @Async
We can decouple email sending from user registration by sending them in asynchrounous way.
Using @Async is the simplest way to decouple email sending from the registration request in Spring Boot.
Executes a method in a separate thread
The HTTP request thread returns immediately
Email sending happens in the background
This reduces API latency and improves throughput.
User service (registration stays fast)
Benefits of @Async
Faster API response
Simple to implement
No infrastructure required
Good for low–medium throughput systems
Cons
An email may be sent even if the transaction rolls back
No retry mechanism
No delivery tracking
Tightly coupled to the application lifecycle
2.Event-Driven Approach
This approach solves the transactional safety problem while still keeping operations asynchronous.
Why AFTER_COMMIT matters
Email is sent only if DB transaction succeeds
Prevents sending emails for rolled-back registrations
Limitations
Still in-process
No durability if app crashes
Limited retry control
3.Outbox Pattern
This solution ensures that side-effects only happen if the transaction succeeds, and can be reliably retried if they fail.
Concept:
Create an outbox table in the database
When performing the main transaction:
Save the core entity and insert a row in the outbox table in the same DB transaction
A separate process (worker / scheduler) reads pending outbox rows and performs the side-effect (e.g., send email, publish event)
Mark the row as processed
Guarantees:
Email is sent only if user exists
Retries are safe
Crash recovery possible
Outbox Table
Both inserts happen atomically. If the transaction rolls back → nothing is written → email is never sent.
Worker to Send Emails
Pros:
Transactional safety - Outbox row inserted only if main transaction succeeds
Reliable retries - Worker can retry until success
Crash-safe - Pending outbox rows survive JVM/app crashes
Decoupled side-effects - Worker can scale independently
Distributed-ready - Can publish to Kafka, RabbitMQ, or other microservices
Cons:
Requires a polling worker or scheduling mechanism
Slight latency between commit and side-effect
Needs cleanup of old rows
For very high throughput, may need batch processing / bulk updates
One callout is that, we can have reliable delivery of email but we can still have duplicate email send.
for example:
Worker crashes after sending, before marking SENT
1. Worker reads PENDING outbox row
2. Sends email successfully
3. App crashes before updating status = SENTAfter restart:
Row is still
PENDINGWorker retries
Email is sent again
Outbox guarantees reliability, not uniqueness. Exactly-once delivery is extremely hard and often impossible across systems. Best practice is to At-least-once + idempotency.
📚 Helpful Resources (7)
30+ Real-World Use Case-Based Java/Spring Boot Interview Questions
Everything Bundle (Java + Spring Boot + SQL Interview + Certification)
📢 Get actionable Java insights every week — from practical code tips to expert interview questions you can use today.
Join 3200+ subscribers and level up your Spring & backend skills with hand-crafted content — no fluff.
Some of you have reached out to my email for some discounts on an annual subscription. I understand that for recent graduates and students, it’s challenging to pay $30 per year. I would like to offer an additional 40% discount ($ 12 per year) until January 31st.
Not convinced? Check out the details of the past work
Precise and clear explanation