Three brokers, three questions, one set of measurements. Ordering, replay, consumer scaling and operational footprint measured against real Kafka 4.2.1, RabbitMQ 3.10.25 and Pulsar 4.2.4 brokers, ending in a decision table where every row has a transcript behind it — including the client-side buffer that silently defeats consumer fan-out in two of the three.
Scale a Spring Boot deployment to three replicas and every @Scheduled method runs three times per tick. Measured on Boot 4.1.1 and PostgreSQL: 24 executions where 8 were due, a @SchedulerLock annotation that silently does nothing without @EnableSchedulerLock, a single scheduler thread that fires 35 of 40 executions in a burst rather than skipping them, and a node whose clock is 40 seconds fast taking a lock somebody else is holding.
@Async is a proxy, and every surprising thing it does follows from that. Measured on Spring Boot 4.1.1 and JDK 25: the self-invocation trap, the IllegalArgumentException a plain return type throws, why max-size does nothing until queue-capacity is bounded, two Executor beans leaving @Async on an unpooled SimpleAsyncTaskExecutor, the new spring.task.execution.propagate-context property, and JEP 491 measured at 4806 ms on JDK 21 against 301 ms on JDK 25.
What Spring Kafka actually does when your listener throws, measured rather than described: the stock DefaultErrorHandler is ten deliveries zero milliseconds apart and then the record is dropped. Plus the poison pill that stops a partition before any listener exists, the DLT suffix that changed to -dlt so a misconfigured recoverer logs a warning and loses the record, why a dead-lettered poison pill arrives base64-encoded, why kafka_dlt-exception-fqcn is useless for triage, and what @RetryableTopic costs in ordering — with the delivery trace to prove it.
All four AMQP exchange types against a real broker, manual acknowledgement, and a dead-letter path that actually works — including the three triggers that fill a DLQ, the one that never does, and the message that vanishes with no error at all. Why publisher-returns and mandatory are two settings in two different places, why basicNack with requeue=true is an infinite loop that never dead-letters and never raises a queue-depth alarm, what x-death.reason tells you that nothing else does, and why changing a queue's TTL is a migration rather than a config edit.
The on-ramp to Spring Kafka under Boot 4, where three things changed at once: adding spring-kafka no longer gives you auto-configuration, JsonSerializer is now the Jackson 2 one and cannot write an Instant, and the default partitioner is not the formula you would write. A producer, a consumer, serialisation, keys and partitions — with every claim run against a real Kafka broker, including the effective-configuration table showing which durability defaults come from Kafka rather than Spring, and why ConsumerFactory.isAutoCommit() answers true while no consumer auto-commits.
Spring Boot 4.1 added InetAddressFilter, a one-bean SSRF control for every auto-configured HTTP client. The release notes call it a way to "block" addresses; the reference documentation says it only allows addresses that match. They are opposite instructions, and acting on the first one produces a service that still leaks internal data and can no longer reach the internet. A working exploit, the allow-versus-block inversion reproduced end to end, why internalAddresses().negate() is not externalAddresses(), how the strength of the filter depends on which HTTP client is on your classpath, and the vararg overload that silently matches nothing.
Four real processes on Spring Boot 4.1.1 and Spring Security 7.1.1, and one uncomfortable finding: by default a resource server accepts any structurally valid, unexpired token from its issuer, including one minted for a completely different service. Relay, client credentials and RFC 8693 token exchange compared by transcript; what Spring Cloud Gateway's TokenRelay actually relays; and why terminating mTLS in a sidecar takes certificate-bound access tokens off the table.
A preflight rejected by Spring Security looks exactly like a CORS misconfiguration, a CSRF token that never reached the browser looks exactly like a bad credential, and a cookie the browser silently refused to store looks exactly like a server that forgot to send it. Verified against Spring Boot 4.1.1 and Spring Security 7.1.1: why MVC-layer CORS cannot fix a security-layer rejection, the bean name that decides whether your configuration is read at all, what csrf.spa() actually assigns, and why SameSite=None without Secure is not a weaker cookie but no cookie.
The sixteen filters Spring Security 7.1 puts in your chain, their exact order numbers, where addFilterBefore actually lands, and four failure modes that produce a 401, a 500, or a filter that is in the chain and never runs. Every table printed from a running Spring Boot 4.1.1 application.