--- title: Pitfalls of Language Runtimes and Multi-tenant | daily.dev description: Language runtimes like Go make concurrent multi-tenant services easy to build by scheduling goroutines fairly, but this fairness is an illusion that breaks... canonical: https://daily.dev/posts/pitfalls-of-language-runtimes-and-multi-tenant-oqljg0ptf twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Pitfalls of Language Runtimes and Multi-tenant | daily.dev og:description: Language runtimes like Go make concurrent multi-tenant services easy to build by scheduling goroutines fairly, but this fairness is an illusion that breaks... og:url: https://daily.dev/posts/pitfalls-of-language-runtimes-and-multi-tenant-oqljg0ptf og:image: https://api.daily.dev/og/posts/OqLJG0PTf.png og:image:alt: Pitfalls of Language Runtimes and Multi-tenant og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Pitfalls of Language Runtimes and Multi-tenant **[Teleport](https://daily.dev/sources/teleport)** · 10 min read · 0 upvotes · 0 comments ## Summary Language runtimes like Go make concurrent multi-tenant services easy to build by scheduling goroutines fairly, but this fairness is an illusion that breaks down when the Linux kernel's CPU scheduling is bypassed. Two worked examples show how a single CPU-bound tenant (an inefficient factorial computation) or a malicious payload (a decompression bomb) can starve or crash the entire process, taking down service for every tenant. Cgroups are presented as a practical mitigation, letting operators cap CPU and memory per process, with Kubernetes cited as an easier way to apply these constraints. The piece concludes that running each tenant as a separate process with cgroup limits is the current best workaround, since no language runtime yet solves this problem at the language level. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does one tenant's CPU-heavy request slow down or crash all other tenants in a Go multi-tenant service? Go's goroutine scheduler provides fair scheduling only for I/O-bound work relying on epoll and blocking calls; it lacks visibility into raw CPU-bound computation. A single goroutine running an inefficient, tight loop (like an unbounded factorial calculation) can monopolize the CPU under GOMAXPROCS=1, starving other goroutines and degrading the whole service for every tenant. _Anyone hardening a multi-tenant Go service against noisy-neighbor CPU spikes can track patterns like this on daily.dev._ ### How can a gzip decompression bomb crash a multi-tenant Go service? A specially crafted small gzip archive can expand to gigabytes of data when decompressed, exhausting available memory. In a demonstrated multi-tenant word-counting service, feeding roughly half of 100 concurrent tenant requests a 10GB decompression bomb caused the process to run out of memory and get killed by the operating system, taking down service for every tenant sharing that process. _Teams worried about resource-exhaustion attacks in shared services can follow decompression-bomb defenses on daily.dev._ ### How do I use Linux cgroups to limit CPU usage for a single process? Create a cgroup directory under /sys/fs/cgroup/cpu, write the process PID into its cgroup.procs file, then set cpu.cfs_period_us (e.g. 1000000 for a 1-second window) and cpu.cfs_quota_us (e.g. 200000 for 20% of one CPU core). Quotas can be adjusted live by writing a new value to cpu.cfs_quota_us without restarting the process. _Developers isolating noisy tenants at the OS level can dig into cgroup configuration walkthroughs on daily.dev._ ## Similar posts on daily.dev - [Go CPU and Memory Requests and Limits in Kubernetes](https://daily.dev/posts/go-cpu-and-memory-requests-and-limits-in-kubernetes-rg4antgzq) · LearnKube · 1 upvotes · 1 comments - [Kubernetes Requests and Limits: How to Right-Size Pods Without Breaking Reliability](https://daily.dev/posts/kubernetes-requests-and-limits-how-to-right-size-pods-without-breaking-reliability-2idykp32g) · Cast AI · 0 upvotes · 0 comments - [Multi-Tenant Best Practices Can Backfire](https://daily.dev/posts/multi-tenant-best-practices-can-backfire-fjwau1jba) · CodeOpinion · 69 upvotes · 5 comments - [Container Runtime Security in Kubernetes: What Teams Overlook](https://daily.dev/posts/container-runtime-security-in-kubernetes-what-teams-overlook-5c69ilqbt) · Cloud Native Now · 8 upvotes · 0 comments --- Tags: [#linux](https://daily.dev/tags/linux), [#golang](https://daily.dev/tags/golang), [#multi-tenancy](https://daily.dev/tags/multi-tenancy) [View this post on daily.dev](https://daily.dev/posts/pitfalls-of-language-runtimes-and-multi-tenant-oqljg0ptf) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Pitfalls of Language Runtimes and Multi-tenant","url":"https://daily.dev/posts/pitfalls-of-language-runtimes-and-multi-tenant-oqljg0ptf","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/pitfalls-of-language-runtimes-and-multi-tenant-oqljg0ptf"},"datePublished":"2026-08-23T12:23:07.499Z","dateModified":"2026-08-23T12:56:13.081Z","description":"Language runtimes like Go make concurrent multi-tenant services easy to build by scheduling goroutines fairly, but this fairness is an illusion that breaks...","image":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","thumbnailUrl":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","isAccessibleForFree":true,"articleSection":"Teleport","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Teleport","logo":"https://media.daily.dev/image/upload/s--Dw-Bbw6O--/c_limit,w_256/f_auto,q_auto/v1787487494/logos/teleport?_a=BAMAMicg0","url":"https://daily.dev/sources/teleport"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/pitfalls-of-language-runtimes-and-multi-tenant-oqljg0ptf","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"linux,golang,multi-tenancy","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Teleport","item":"https://daily.dev/sources/teleport"},{"@type":"ListItem","position":3,"name":"Pitfalls of Language Runtimes and Multi-tenant"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/pitfalls-of-language-runtimes-and-multi-tenant-oqljg0ptf#faq","mainEntity":[{"@type":"Question","name":"Why does one tenant's CPU-heavy request slow down or crash all other tenants in a Go multi-tenant service?","acceptedAnswer":{"@type":"Answer","text":"Go's goroutine scheduler provides fair scheduling only for I/O-bound work relying on epoll and blocking calls; it lacks visibility into raw CPU-bound computation. A single goroutine running an inefficient, tight loop (like an unbounded factorial calculation) can monopolize the CPU under GOMAXPROCS=1, starving other goroutines and degrading the whole service for every tenant. Anyone hardening a multi-tenant Go service against noisy-neighbor CPU spikes can track patterns like this on daily.dev."}},{"@type":"Question","name":"How can a gzip decompression bomb crash a multi-tenant Go service?","acceptedAnswer":{"@type":"Answer","text":"A specially crafted small gzip archive can expand to gigabytes of data when decompressed, exhausting available memory. In a demonstrated multi-tenant word-counting service, feeding roughly half of 100 concurrent tenant requests a 10GB decompression bomb caused the process to run out of memory and get killed by the operating system, taking down service for every tenant sharing that process. Teams worried about resource-exhaustion attacks in shared services can follow decompression-bomb defenses on daily.dev."}},{"@type":"Question","name":"How do I use Linux cgroups to limit CPU usage for a single process?","acceptedAnswer":{"@type":"Answer","text":"Create a cgroup directory under /sys/fs/cgroup/cpu, write the process PID into its cgroup.procs file, then set cpu.cfs_period_us (e.g. 1000000 for a 1-second window) and cpu.cfs_quota_us (e.g. 200000 for 20% of one CPU core). Quotas can be adjusted live by writing a new value to cpu.cfs_quota_us without restarting the process. Developers isolating noisy tenants at the OS level can dig into cgroup configuration walkthroughs on daily.dev."}}]} ```