Summary
In messageService/src/main/java/org/example/messageservice/service/MessageService.java, the toResponse mapping method calls userGrpcClient.getUserByUsername() for every message individually. This means findAll() and findBySenderId() trigger one blocking gRPC call per message, which could cause significant latency at scale (e.g., 50 messages × 2 s deadline = up to 100 s worst case).
Suggested approaches
- Batch lookup: Introduce a bulk gRPC endpoint on the user service and collect all distinct sender usernames first, resolve in a single call, then map results back.
- Short-TTL in-memory cache: Cache resolved usernames (e.g., with Caffeine or a simple
ConcurrentHashMap) to avoid repeated lookups for the same sender.
- Parallelization: Use async executors /
CompletableFuture to fan out concurrent lookups if the user service can handle the load.
References
Reported by @coderabbitai on behalf of @simonforsberg.
Summary
In
messageService/src/main/java/org/example/messageservice/service/MessageService.java, thetoResponsemapping method callsuserGrpcClient.getUserByUsername()for every message individually. This meansfindAll()andfindBySenderId()trigger one blocking gRPC call per message, which could cause significant latency at scale (e.g., 50 messages × 2 s deadline = up to 100 s worst case).Suggested approaches
ConcurrentHashMap) to avoid repeated lookups for the same sender.CompletableFutureto fan out concurrent lookups if the user service can handle the load.References
Reported by @coderabbitai on behalf of @simonforsberg.