diff --git a/_posts/2023-09-19-virtual-thread-1.adoc b/_posts/2023-09-19-virtual-thread-1.adoc
index 1e451b74ba1..aa9394d7447 100644
--- a/_posts/2023-09-19-virtual-thread-1.adoc
+++ b/_posts/2023-09-19-virtual-thread-1.adoc
@@ -75,8 +75,8 @@ But there is a limit to that imperative model.
 You can only handle _n_ requests concurrently, with _n_ the number of threads the framework can create.
 OS threads are expensive. 
 They consume memory (around 1 Mb per thread), are expensive to create, use CPU to schedule them…
-Frameworks use thread pools to allow reusing idle threads, but when the concurrency level exceeds your number of threads, you start pilling up requests, reducing the response time, and, in the worst case, even rejecting requests.
-Increasing the thread pool size and, consequently, increasing the memory usage can blow up your Cloud bill and deployment density.
+Frameworks use thread pools to allow reusing idle threads, but when the concurrency level exceeds your number of threads, you start pilling up requests, increasing the response time, and, in the worst case, even rejecting requests.
+Increasing the thread pool size and, consequently, swelling the memory usage can blow up your Cloud bill and deployment density.
 Futhermore, adding more threads may not even improve the concurrency as explained by the https://youtu.be/07V08SB1l8c?t=142[Little Law].
 
 The reactive movement proposed an alternative model to work around that issue.