Pro Tips — High Traffic Tomcat Thread Pool Tuning and Filter/Interceptor Division

1. Tomcat Thread Pool Tuning

Spring Boot's default embedded servlet container, Apache Tomcat, operates fundamentally on a synchronous Thread-per-Request model. If massive traffic hits the instance concurrently without fail-safes, Thread Exhaustion can immediately crash the server process.

Tuning the attributes in application.yml below proportionally to your exact hardware limitations is an indispensable production skill.

server:
  tomcat:
    threads:
      max: 200 # Maximum simultaneous allowed threads the server spins up (Default 200)
      min-spare: 10 # Minimum idle backup threads constantly kept alive (Default 10)
    accept-count: 100 # Maximum backlog backlog requests queued by OS when all threads are busy
    connection-timeout: 20000 # Maximum millisecond wait time before dropping a slow client socket connection

tip

Simply increasing the max threads infinitely to 10,000 under high traffic conditions will invariably slow down your entire architecture due to explosive CPU Context Switching operational overheads. It's imperative to calculate a "magic number" iteratively using stress benchmarking tools (JMeter, nGrinder), considering your actual vCPU cores constraint, Database Connection Pool size ratio, and external API latency.

2. Security at the Filter step, Business Rules at the Interceptor step

As reviewed previously, both Filters and Interceptors intercept and manipulate incoming client routing paths. However, there is a clear strategic division architectural principle applied commonly in practical workspaces:

• Filter: Given that it executes earliest at the raw Servlet phase prior to the Spring Context initiation, you delegate global Web layer security passes here. That includes raw payload XSS filtering attack defense, parameter obfuscation checks, and basic port-level CORS verifications.
• Interceptor: Interceptors have in-depth reflective access to the deep internals of the Spring Context (like assessing the target Controller method's identity and retrieving deep user authentication caching sessions). Thus, they are practically implemented for specialized granular Business Rules—such as nuanced Authorization logic checks (@PreAuthorize behaviors) and User Membership tiered API Rate Limiting thresholds.