Debugging Slow Update Calls in a Microservice Backend: Analysis and Fixes

Problem description: After a recent deployment, a backend update operation became extremely slow, taking up to 10 seconds and causing performance concerns.

Analysis: Log tracing revealed two RPC calls with retry=1, leading to duplicate updates; the update statement uses a primary‑key but still takes long. Investigation showed row‑lock contention between Service A and Service B, with asynchronous tasks sometimes running in the original thread due to a thread‑pool failure strategy. The thread‑pool configuration caused insufficient threads and unexpected execution paths.

Code snippet of the problematic update:

update table set a=#{1},b=#{2},... where id=#{0} (id primary key)

Solution: Adjust thread‑pool parameters (set core and max threads equal, increase queue size to 9999) to ensure sufficient threads, remove retry for write operations, and separate the transaction from the Service A → Service B call to avoid lock contention. Two implementation options are presented: an ideal full microservice refactor and a practical immediate fix.

Summary: The root cause was RPC retry combined with thread‑pool misconfiguration causing lock competition; fixing the thread pool and eliminating unnecessary retries restored normal performance.