Bulkhead vs Rate limiting.

Mahendar Anumalla — Wed, 20 May 2026 14:47:30 +0000

Rate Limiter (Time-based): A client can make 100 requests in a minute. Assume you have a fleet of automated clients or “boats” doing ping tests. If we don’t set a limit, they can spam the system with infinite requests and absolutely kill the servers. Rate limiting throttles them based on a clock.

Bulkhead (Concurrency-based): Bulkhead counts the number of active, in-flight calls made to a downstream service. It cares about how many calls are currently processing and waiting for a response. Assume a developer accidentally creates an infinite loop that calls a downstream service across multiple threads simultaneously. Without a bulkhead, your resources get completely exhausted, and your service is gone.

Basic Settings for Bulkhead:

Resilience4j:

     Bulkhead:

    fastMethodBulkhead:

   type: SEMAPHORE or Thread

   maxConcurrentCalls: 10   // number of calls can make

    maxWaitDuration: 500ms   // max time it can wait before failing.

   queueCapacity: 10        // number of threads can wait in the queue.

        keepAliveDuration 10s.       //They can wait in the waiting queue.

fastMethodBulkhead:
type: THREADPOOL
max-concurrent-calls: 20
max-wait-duration: 200ms
queueCapacity: 10
keepAliveDuration 10s

@Bulkhead(name = “fastMethodBulkhead”, type = Bulkhead.Type.SEMAPHORE)

public String getQuickReview(String hotelId) {

return quickClient.getReviews(hotelId);

}

// Long-running method - fewer concurrent threads

@Bulkhead(name = “longMethodBulkhead”, type = Bulkhead.Type.THREADPOOL)

public String getFullReview(String hotelId) {

return slowClient.getDetailedReviews(hotelId);

}

We can override the bulkhead at method level using the service name, all methods need not to follow the same timings.

When bulkhead rejects the request, it is fail-fast and throws a BulkheadFullException.

Semaphore Vs ThreadPool

Semaphore is counter based, based on the count it will allow concurrent threads. use the caller/main thread to update the counter. faster compare to thread pool.
Thread Pool use a separate thread to tract the count and executed asynchronously

# Mastering Spring Security: Architecture, JWT Patterns, and Production Gotchas

Mahendar Anumalla — Wed, 20 May 2026 09:32:48 +0000

If you have ever integrated Spring Security into an enterprise application, you know it feels like magic—until a random 401 Unauthorized or 403 Forbidden breaks your production build.

To build secure, predictable APIs, you have to look past the boilerplate annotations and understand how Spring Security coordinates filters, manages authentication contexts, and delegates authorization. Let's break down how the internal engine works, look at optimal JWT strategies for microservices, and tackle common interview and production questions.

1. The Core Architecture Blueprint

Every request entering a secure Spring Boot application journeys through a layered ecosystem before it ever hits your @RestController.

The Request Lifecycle Pipeline

Request ➔ DelegatingFilterProxy ➔ SecurityFilterChain (Authentication Filter) 
        ➔ AuthenticationManager ➔ AuthenticationProvider ➔ UserDetailsService 
        ➔ SecurityContextHolder ➔ AuthorizationFilter ➔ Your Controller

The Gateway (DelegatingFilterProxy): Servlet containers don't natively know about Spring beans. This proxy bridges the gap, handing the request over to Spring's managed SecurityFilterChain.
The Interceptor (AuthenticationFilter): Filters extract raw credentials. For instance, a BasicAuthenticationFilter looks for a header starting with Basic, decodes the Base64 payload, and extracts the username and password.
The Tokenization: Once extracted, the filter wraps these raw credentials into an unauthenticated token object, such as a UsernamePasswordAuthenticationToken.
The Coordinator (AuthenticationManager): The manager (typically implemented as ProviderManager) holds a registry of available AuthenticationProvider instances. It loops through them, matching a provider via its .supports(Class<?> authentication) method.

// Simplified look under the hood of ProviderManager
for (AuthenticationProvider provider : getProviders()) {
   if (!provider.supports(toTest)) {
       continue;
   }
   try {
       result = provider.authenticate(authentication);
       if (result != null) {
           copyDetails(authentication, result);
           break; // Authentication succeeded!
       }
   } catch (AuthenticationException e) {
       // Handled appropriately or thrown down the line
   }
}

The Resolver (AuthenticationProvider & UserDetailsService): The provider calls your database or identity provider (via UserDetailsService), matches the passwords, and returns a fully populated, authenticated Authentication object.

2. Authentication Outcomes: Success vs. Failure

What happens right after the AuthenticationManager completes its evaluation?

On Success: Populating ThreadLocal

The engine constructs a Principal object containing user information and roles, then injects it directly into the SecurityContextHolder. By default, this uses a ThreadLocal strategy.

Architectural Win: Because it is stored in a ThreadLocal wrapper, the active user's context stays accessible across any controller, service, or repository executed within that specific request thread—without forcing you to pass user objects as method arguments.

On Failure: The Exception Translation Layer

If credentials mismatch, an exception is thrown. The AuthenticationManager bubbles this back to the filters. This is where the ExceptionTranslationFilter shines: it intercepts the security exceptions and translates them into appropriate HTTP responses (like a 401 Unauthorized challenge or custom JSON payload) via the configured AuthenticationEntryPoint.

3. Stateful vs. Stateless Context Management

How your application remembers authenticated users depends heavily on your architecture layout:

Aspect	Stateful Session	Stateless (JWT / Basic Auth)
Storage Location	Server memory (`HttpSession`)	Client-side Token
Re-Identification	Tracks requests using a `JSESSIONID` cookie	Inspects incoming token header on every request
Filter Handling	`SecurityContextHolderFilter` extracts context from the session	Token filter builds context completely fresh per request
Thread Strategy	Cleared out and reloaded from session store	Cleared completely at the end of the thread lifecycle

4. The JWT Pattern for Distributed Microservices

When implementing stateless JSON Web Tokens, you will usually extend OncePerRequestFilter. This ensures your validation logic triggers exactly once per request lifecycle, bypassing edge cases where internal servlet forwards or redirects double-trigger a regular filter.

Incoming Request ➔ JWT Filter ➔ .parseClaimsJws(token) [Validates Signature & Expiry] ➔ Set SecurityContext ➔ Chain Continues

Propagating JWT Tokens Downstream

In a microservices ecosystem, you have two primary options when Service A needs to call Service B:

Token Propagation (Impersonation): Forward the original client token received by your controller to downstream services.
Service-to-Service Identity: Service A obtains its own dedicated machine-to-machine JWT from the Authorization Server (cached until expiry) and attaches it to calls bound for Service B.

If you are using the Token Propagation approach, you don't need to rebuild the string payload manually from user fields. Spring Security caches the raw token value inside the security context:

// Extracting the original token inside a RestTemplate/WebClient Interceptor
String token = ((Jwt) SecurityContextHolder.getContext()
       .getAuthentication().getPrincipal())
       .getTokenValue();

// Attach 'token' to the Authorization Bearer header for outbound calls

5. Method-Level Security & Role Hierarchies

By dropping @EnableMethodSecurity on a configuration class, Spring creates runtime proxies around your beans, using Aspect-Oriented Programming (AOP) to evaluate security rules before or after a method fires.

Setting up a Clean Role Hierarchy

Instead of cluttering your code with complex expressions like @PreAuthorize("hasAnyRole('SALESREP', 'ADMIN')"), clean it up by declaring a logical hierarchy bean. This ensures an ADMIN implicitly inherits all capabilities belonging to a SALESREP.

@Bean
public RoleHierarchy roleHierarchy() {
    RoleHierarchyImpl hierarchy = new RoleHierarchyImpl();
    hierarchy.setHierarchy("ROLE_ADMIN > ROLE_SALESREP");
    return hierarchy;
}

Overriding Hierarchy Defaults & Custom Beans

If you run into an isolated edgecase where an endpoint must be accessed by a SALESREP but explicitly blocked for an ADMIN, combine logical operators or delegate to a custom Spring component:

// Inline evaluation override
@PreAuthorize("hasRole('SALESREP') and !hasRole('ADMIN')")

// Delegation to a specialized security service
@PreAuthorize("@securityService.canAccessLead(authentication)")

When to leverage `@PostAuthorize`

While @PreAuthorize prevents a method from starting if criteria aren't met, @PostAuthorize allows a method to completely execute, evaluates the returned entity, and throws an Access Denied exception if conditions fail. This is ideal for domain-driven permissions:

@PostAuthorize("returnObject.isPublic() or returnObject.getOwner() == authentication.name")
public Document findDocumentById(Long id) {
    return documentRepository.findById(id); 
}

6. Real-World Production Deep Dive (Q&A)

Q: If a security chain features multiple filters, can we skip remaining filters once one successfully authenticates the request?

No, but also Yes. The structure of a FilterChain is static; once built, the request must physical pass through every node in that sequence to reach the servlet. However, you can skip the heavy internal execution logic inside your custom filters by wrapping your functional logic in a conditional check (e.g., executing only if SecurityContextHolder.getContext().getAuthentication() == null). If it is already authenticated, the filter can immediately invoke filterChain.doFilter(request, response) and return early.

Q: How do we handle Blacklisting/Logouts for stateless JWTs?

Because JWTs are self-contained and stateless, they remain valid until their expiration date, even if a user logs out.

The Scalable Approach: Keep token life-cycles highly restricted (e.g., 15 minutes) to minimize windows of vulnerability.
The Strict Approach: Upon logout, record the token signature into a fast, centralized key-value data cache like Redis with a Time-To-Live (TTL) tracking its remaining validity duration. On subsequent filter evaluations, query Redis. If the token matches the blacklist, halt the request execution.

Q: What if a JWT token expires right in the middle of downstream processing?

Spring Security introduces a default clock skew tolerance configuration (typically 60 seconds) to account for slight server time variances across instances. To survive unexpected mid-flight expiration scenarios across deeper, time-consuming service calls, ensure downstream services implement sensible internal network timeout/tolerance settings or use API gateways that renew downstream-bound tokens automatically.

Q: Why are users experiencing random 401 Unauthorized or 403 Forbidden errors?

Clock Drift: If your distributed cluster nodes drift out of sync temporally, a token minted on Server A might be treated as prematurely expired or not-yet-valid by Server B. Ensure all cluster nodes use Network Time Protocol (NTP) daemons to keep system clocks tightly aligned.
Configuration Conflicts: If a URL path pattern is protected via your SecurityFilterChain settings (e.g., requiring .hasRole("ADMIN")) but the underlying method controller is annotated with an explicit @PreAuthorize("hasRole('USER')"), both criteria must pass. A configuration mismatch here results in a frustrating 403 Forbidden response.
Token Refresh Failures: Front-end clients missing precise execution loops for silent token-refresh operations often send expired signatures, causing unexpected 401 Unauthorized errors during normal user flows.

DEV Community: Mahendar Anumalla