$ mvn -pl cqrs test -Dtest=SyncProfileLatencyTest
(default profile -- SyncOrderSummaryProjection active; its write to order_summary runs
 on the same thread that is about to answer the command's HTTP request)

2026-10-04T02:27:21.596+05:30  INFO 17202 --- [cqrs] [           main] com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 - Added connection conn0: url=jdbc:h2:mem:cqrs-write user=SA
2026-10-04T02:27:22.729+05:30  INFO 17202 --- [cqrs] [           main] com.zaxxer.hikari.pool.HikariPool        : HikariPool-2 - Added connection conn10: url=jdbc:h2:mem:cqrs-read user=SA

POST /orders (sync profile) took 670 ms, orderId=9ee5b016-7a81-40f9-8d7a-d7d1959c09be
Immediately after POST returned, GET /order-summaries/9ee5b016-7a81-40f9-8d7a-d7d1959c09be -> status=200 OK, body=OrderSummary[orderId=9ee5b016-7a81-40f9-8d7a-d7d1959c09be, customerName=Priya, itemCount=2, totalCents=7597, status=PLACED, updatedAt=2026-10-03T20:57:24.283700Z]

[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

Two real HikariCP pools, one per DataSource bean -- that line alone is a cheap way to
confirm the write and read sides really are two separate connection pools to two separate
H2 databases, not one database with two tables. The 670ms includes the 300ms the projection's
simulated write delay adds on top of real JPA/Hibernate first-request costs (see
output/01-async-profile-staleness-window.txt's warm-up note for what that baseline actually
is) -- and because that write finished before the HTTP response did, the very next GET
against the read model, with no wait at all, already sees itemCount, totalCents and status
correctly populated.