We get asked this often enough that it’s worth writing down: why does Ellomas use Go for most of its infrastructure work?
The short answer: Go’s concurrency model, deployment story, and performance characteristics are the best fit for the systems we build most often. Not because Go is the “best” language. Because it’s the right one for our specific constraints.
Here’s the longer version.
What We Actually Build
Most of our infrastructure work falls into a few categories:
- Payment processing services that handle thousands of concurrent transactions
- Background job systems that process queues reliably without losing work
- API gateways and proxies that route traffic between services
- Webhook relay systems that receive, validate, and forward events
These all share a pattern: high concurrency, mostly I/O-bound, needs to stay up. The language choice for this kind of work matters more than most developers think.
What Go Gets Right for Us
Goroutines are the right abstraction for concurrent I/O. When a payment service needs to handle 5,000 simultaneous webhook deliveries, Go lets us spin up 5,000 goroutines at roughly 2KB each. In Node.js, we’d be managing callback chains or promise pools. In Java, we’d be managing thread pools. Go makes the concurrent case feel like the normal case, because it is.
If you want the technical deep dive on how this works under the hood, we wrote a full article on concurrency models across Go, Node.js, and C#.
Single binary deployment is underrated. go build produces one binary with no runtime dependencies. No node_modules, no JVM, no dependency resolution at deploy time. We copy the binary to the server, run it. For infrastructure services that need to be reliable, fewer moving parts at deployment time means fewer things that can go wrong.
The standard library is production-grade. Go’s net/http, encoding/json, crypto, and database/sql packages are genuinely good enough for production use without third-party libraries. We use fewer dependencies, which means fewer supply chain risks and fewer breaking upgrades.
Explicit error handling makes failures visible. Go’s if err != nil pattern is tedious. It is also extremely effective at forcing engineers to think about what happens when things go wrong. In payment systems, silently swallowed exceptions are how you lose money.
Where Go Doesn’t Fit
We don’t use Go for everything. Honest assessment:
Rapid prototyping and MVPs. When a client needs a proof-of-concept fast, Node.js with Express gets us there quicker. The ecosystem is larger, iteration is faster, and the prototype doesn’t need to handle 5,000 concurrent connections.
Frontend-adjacent work. For server-rendered pages, API routes that sit close to the frontend, or full-stack applications, we reach for Node.js or the framework the client’s team already uses.
Data science and ML pipelines. Python owns this space for good reason. We wouldn’t try to build a model evaluation pipeline in Go.
Heavy ORM-driven CRUD applications. If the project is primarily database reads and writes with complex relationships, C# with Entity Framework or Node.js with Prisma are better fits. Go’s database tooling is deliberately minimal, which is a strength for infrastructure and a friction point for CRUD-heavy applications.
The Decision Framework
When we evaluate language choice for a new project, we ask three questions:
-
What’s the concurrency profile? If the service handles many simultaneous connections or background jobs, Go. If it’s request-response CRUD, the team’s strongest language.
-
What does the deployment environment look like? If we’re deploying to minimal infrastructure (small VPS, edge workers, containers), Go’s single binary wins. If there’s already a Node.js or .NET ecosystem in place, we work within it.
-
Who maintains it after us? If the client’s team knows JavaScript, we’re not going to hand them a Go codebase they can’t maintain. The best language choice is the one the team can operate confidently.
The Honest Summary
Go is not the most expressive language. It’s not the most productive for every task. It doesn’t have the richest ecosystem.
What it does have is a concurrency model that maps directly to the problems we solve most often, a deployment model that minimizes operational risk, and a performance profile that lets us build infrastructure services that handle real load without exotic optimization.
For the work Ellomas does most often, that’s the right trade-off.
Ellomas Technologies builds reliable software for credit, power, and operations systems. We help teams plan, build, and improve the infrastructure their business depends on.