{"id":2957,"date":"2026-07-01T09:30:00","date_gmt":"2026-07-01T09:30:00","guid":{"rendered":"https:\/\/mugnos-it.com\/?p=2957"},"modified":"2026-07-06T16:39:24","modified_gmt":"2026-07-06T16:39:24","slug":"concurrency-is-not-parallelism-and-confusing-the-two-can-be-costly","status":"publish","type":"post","link":"https:\/\/mugnos-it.com\/pt\/concurrency-is-not-parallelism-and-confusing-the-two-can-be-costly\/","title":{"rendered":"Concurrency is NOT Parallelism! And confusing the two can be costly"},"content":{"rendered":"

A few days ago I got pulled into a curious conversation: the team was excited, implementing autoscaling on queue-consumer pods<\/strong>, trying to increase throughput.<\/p>\n\n\n

All good so far, right?<\/p>\n\n\n

But then came the question:<\/p>\n\n\n

“Why are we spinning up more pods if we’re not even using the resources well inside a single pod?”<\/em><\/p>\n\n\n

Silence.<\/p>\n\n\n

And that’s exactly where the problem lives. Just because your infrastructure is scalable doesn’t mean you should go full “Let it Go” on the pods \u2014 and leave the bill (of CPU, memory, and chaos) for someone else to deal with.<\/p>\n\n\n

Today, let’s talk about a common mistake: confusing concurrency with parallelism<\/strong>.<\/p>\n\n\n

Spoiler: they’re not the same thing. And the difference between them can decide whether your system scales well<\/strong> or just burns resources<\/strong>.<\/p>\n\n\n

Concurrency \u2260 Parallelism<\/h2>\n\n\n

Concurrency<\/h3>\n\n\n

Concurrency is about dealing with multiple tasks at the same time<\/strong>, but not necessarily executing them simultaneously<\/strong>.<\/p>\n\n\n

It’s as if a single core were handling several things at once, jumping from one to another whenever it hits a wait (like I\/O calls, database access, external APIs, etc).<\/p>\n\n\n

You gain performance not by doing everything at the same time<\/strong>, but by not sitting idle waiting<\/strong>.<\/p>\n\n\n

Practical example:<\/strong><\/p>\n\n\n

    \n
  • A worker consumes a queue, makes a request to an API and\u2026 waits.\n
      \n
    • During that time, it could be processing another task.<\/li>\n\n\n
    • Solution: apply concurrency, like goroutines (Go), lightweight threads (Java), async\/await (Node, Python).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n

      Parallelism<\/h3>\n\n\n

      Parallelism, on the other hand, is when you have multiple cores<\/strong> processing different things at the same time<\/strong>, for real.<\/p>\n\n\n

      Ideal for heavy tasks, like data transformation<\/strong>, batch processing<\/strong>, machine learning<\/strong>, etc.<\/p>\n\n\n

      Practical example:<\/strong><\/p>\n\n\n

        \n
      • Processing 1 million records with Spark, distributing the work across multiple nodes at the same time.<\/li>\n<\/ul>\n\n\n

        But be careful: blind parallelism with heavy I\/O can be inefficient<\/strong>.<\/p>\n\n\n

        You spin up a bunch of workers\u2026 that just sit there waiting for a network response.<\/p>\n\n\n

        When to use each one?<\/h2>\n\n\n

        Use concurrency when\u2026<\/strong><\/p>\n\n\n

          \n
        • Your code depends on external calls (APIs, databases, legacy systems)<\/li>\n\n\n
        • You want better utilization of a single resource (e.g. a pod)<\/li>\n<\/ul>\n\n\n

          Use parallelism when\u2026<\/strong><\/p>\n\n\n

            \n
          • You’re dealing with CPU-bound<\/strong> tasks<\/li>\n\n\n
          • You need to scale real processing, not just orchestration<\/li>\n<\/ul>\n\n\n

            Even though I explain them separately, using one doesn’t rule out the other! In fact, you need to use both \u2014 but the way you implement each is different.<\/p>\n\n\n

            Think of it like this: inside a single pod<\/strong>, you use concurrency so you don’t waste time sitting in waits. Once that pod is already at a healthy limit, then<\/em> you scale horizontally (real parallelism, more replicas). Order matters \u2014 scaling before optimizing means paying a premium for inefficiency.<\/p>\n\n\n

            The SRE connection<\/h2>\n\n\n

            This is where it stops being operating-system theory and becomes a reliability and cost decision<\/strong>.<\/p>\n\n\n

              \n
            • Eliminating toil and waste:<\/strong> spinning up a pod by reflex is the opposite of efficiency. Before touching the HPA, look at the real utilization inside<\/em> the pod. If a worker spends 80% of its time waiting on I\/O, the problem isn’t a lack of replicas \u2014 it’s a lack of concurrency.<\/li>\n\n\n
            • Monitoring that matters:<\/strong> CPU and memory aren’t enough. Measure effective per-pod utilization<\/strong>, queue depth, processing latency, and time spent waiting on I\/O. Those signals tell you which<\/em> lever to pull.<\/li>\n\n\n
            • Error budget and blast radius:<\/strong> uncontrolled concurrency turns into race conditions<\/em> and deadlocks<\/em> in production \u2014 and that burns error budget fast. Parallelism without rate limiting<\/em> takes down downstream dependencies. Reliability is about sizing with intention.<\/li>\n\n\n
            • FinOps is an SRE responsibility:<\/strong> every unnecessary replica is money burned every single month. Making good use of a single pod before scaling is cost optimization at its core.<\/li>\n<\/ul>\n\n\n

              And the risks?<\/h2>\n\n\n

              Concurrency without control<\/strong><\/p>\n\n\n

                \n
              • Pushing too much concurrency makes it constantly switch context between tasks (context switching<\/em>), and excessive context switching generates overhead.<\/li>\n\n\n
              • It can blow up into race conditions<\/em>, deadlocks<\/em>, and freeze everything (which is why you need to be careful and handle it with mutexes and locks).<\/li>\n<\/ul>\n\n\n

                Poorly sized parallelism<\/strong><\/p>\n\n\n

                  \n
                • Creating too many pods without evaluating real usage.<\/li>\n\n\n
                • Increasing the number of threads without control (and hardware is finite, remember?).<\/li>\n\n\n
                • Scaling without applying rate limits<\/em> \u2192 a disaster waiting to happen.<\/li>\n<\/ul>\n\n\n

                  Conclusion<\/h2>\n\n\n

                  The difference between concurrency and parallelism may seem subtle, but ignoring it can be costly \u2014 in performance, in money, and in unnecessary complexity.<\/p>\n\n\n

                  Go back to the beginning: the team wanted more pods. But the right question wasn’t “how many replicas?”<\/em> \u2014 it was “am I making good use of what I already have?”<\/em>.<\/p>\n\n\n

                  The truth is that a lot of architecture is being decided on impulse. Solutions get sold as indispensable, the hype takes over\u2026 and suddenly we’re paying a premium for infrastructure that doesn’t even bring real value to the business.<\/p>\n\n\n

                  A good technical choice is one made with intention, clarity, and purpose<\/strong> \u2014 understanding what your system actually needs before you start scaling.<\/p>\n\n\n

                  If this kind of reflection resonates with you, and you want to learn how to use technology to scale your technical capacity (without becoming a hostage to tooling), make sure to follow me on social media and keep up with the newsletter!<\/p>\n\n\n

                  Cheers,<\/p>\n\n\n

                  Douglas Mugnos<\/p>\n\n\n

                  MUGNOS-IT \ud83d\ude80<\/p>","protected":false},"excerpt":{"rendered":"

                  A few days ago I got pulled into a curious conversation: the team was excited, implementing autoscaling on queue-consumer pods, trying to increase throughput. All good so far, right? But then came the question: “Why are we spinning up more pods if we’re not even using the resources well inside a single pod?” Silence. And […]<\/p>","protected":false},"author":3,"featured_media":2977,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2957","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/mugnos-it.com\/wp-content\/uploads\/2026\/07\/59-2.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/2957","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/comments?post=2957"}],"version-history":[{"count":4,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/2957\/revisions"}],"predecessor-version":[{"id":2963,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/2957\/revisions\/2963"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/media\/2977"}],"wp:attachment":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/media?parent=2957"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/categories?post=2957"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/tags?post=2957"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}