Katkat
Back

Design Spring Boot for high availability and background work

Walmart LabsSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This question tests the ability to scale a stateless Spring Boot service while ensuring reliable execution of asynchronous background tasks in a distributed environment.

Scenario

You are tasked with designing a high-availability (HA) architecture for a Spring Boot-based order processing service that must handle 5,000 requests per second and perform long-running background tasks (e.g., generating PDF invoices, sending confirmation emails). The system must remain available during deployments and handle sudden spikes in traffic without losing background tasks.

Requirements

  1. Stateless Architecture: Design the service to be horizontally scalable behind a load balancer.
  2. Session Management: Handle user authentication state across multiple instances.
  3. Background Processing: Architect a mechanism to offload long-running tasks from the main request-response cycle.
  4. Resilience: Ensure that background tasks are not lost if an application instance crashes during processing.
  5. Deployment Strategy: Explain how to deploy updates without dropping active user requests.

Deliverables

  • Provide a high-level architecture diagram or description showing the interaction between the client, load balancer, Spring Boot instances, database, and background task queue.
  • Specify the technologies or Spring patterns you would use for distributed session management and asynchronous messaging.
  • Discuss the trade-offs between different queueing strategies (e.g., persistent message brokers vs. database-backed polling).

Hints

Hint 1

Consider using an externalized session store like Redis to ensure the Spring Boot instances remain truly stateless.

Hint 2

Decouple background processing from the web request thread pool using a messaging system like RabbitMQ or Kafka to improve throughput.

Hint 3

Use a Blue-Green or Rolling update deployment strategy to ensure zero-downtime during rolling restarts of your containerized service.

Follow-up questions

  • How would you handle idempotency for background tasks if a message is delivered more than once by the broker?
  • What observability metrics would you monitor in your Spring Boot application to trigger an auto-scaling event?
  • If the background task queue grows too fast, how would you implement rate limiting or backpressure mechanisms?