Travis McCracken argues for fewer, sharper microservices

Web developer Travis McCracken’s DEV Community post uses Rust, Go, and fictional backend projects to make a practical point: teams should choose service boundaries with care before they multiply microservices.

McCracken frames Rust and Go as strong backend tools, but the sharper lesson sits in the architecture choices around them. A team can use Rust for low-latency cache work and Go for HTTP services, yet still create a fragile system if engineers split code into too many deployable parts.

Microservices help when a team owns a bounded capability, ships it without coordinating with half the company, and accepts the operational cost. They hurt when engineers use them as a default project shape. Each new service adds deploy pipelines, logs, metrics, secrets, retries, timeout rules, schema versioning, and incident paths. A small team can spend more time operating the architecture than improving the product.

McCracken’s examples, including fastjson-api, rust-cache-server, and go-microservice-auth, show a better starting point. Pick the language for the workload first. Then pick the boundary. A cache server, an authentication service, and a public JSON API each has a different performance profile and failure mode.

A Rust cache layer can make sense when engineers need tight memory control, low tail latency, and predictable CPU use. Rust’s ownership model helps engineers prevent whole classes of memory errors before deployment. The Tokio runtime gives Rust teams an async foundation for network services that handle many open connections.

Go fits a different job. Engineers can build a small HTTP API with the standard net/http package, add concurrency with goroutines, and keep the code readable for a broad team. Go’s toolchain also reduces friction in build, test, and dependency workflows through go mod.

The service boundary matters more than the language logo. A team that splits authentication, billing, search, and caching into separate services accepts network calls as part of the application’s control flow. That choice changes latency, failure handling, and data consistency.

A monolith can call a local function and share a transaction. A microservice must cross the network. The caller needs a timeout. The callee needs capacity limits. Both sides need schema compatibility. Engineers must decide whether the caller retries, queues the request, drops it, or returns an error to the user.

Consistency gets harder first. If a user changes an email address in one service and another service reads stale profile data for 30 seconds, engineers must decide whether the product can tolerate that gap. Some systems can. A social profile page can accept stale reads for a short period. A payment workflow cannot treat stale authorization data as harmless.

That choice defines the consistency model. Engineers can keep strong consistency inside one database boundary. They can use eventual consistency across services when the product accepts delayed agreement. They can also build compensating actions, idempotency keys, and reconciliation jobs. Each option gives the team a tool and a burden.

API design absorbs that burden. REST endpoints work well for public resources and broad compatibility. gRPC fits internal service calls that need typed contracts, streaming, or low overhead. Event-driven APIs help teams decouple producers from consumers, but engineers must then handle duplicate messages, out-of-order events, and replay.

McCracken’s fictional rust-cache-server points at one clean split: a specialized infrastructure service with a narrow contract. Engineers can expose commands for get, set, expiration, and replication. The application team can treat cache failures as degraded performance instead of lost source-of-record data.

That distinction protects the system. A cache can fail open if the database remains available. An authentication service cannot fail open without creating a security incident. A recommendation service can time out and return defaults. A checkout service needs a stricter path.

Too many microservices blur those differences. A team may end up with five small services that each own a tiny piece of one user action. A login request might touch an identity service, a token service, a profile service, a risk service, and an audit service. Each hop adds latency and a new way to fail.

Engineers can make that design work, but they need mature operations. They need distributed tracing, service-level objectives, deployment gates, contract tests, and an incident process that tells responders which service owns the broken behavior. Without that base, a service map turns into a debugging maze.

A better rule starts with ownership. Split a service when one team can own its data, API, deployment schedule, and on-call burden. Keep code together when the same team owns all of it and changes it as one unit. A module boundary inside a monolith can enforce design discipline without network cost.

Data ownership gives the rule teeth. If two services need to write the same table, the boundary has failed. If one service exposes a stable API over its own data and other services can live with that contract, the boundary has value. The database should follow the ownership line, because shared tables create hidden coupling that service names cannot hide.

McCracken’s Rust and Go pairing can serve that model. Engineers can build a high-throughput Rust cache service for a narrow hot path. They can build Go APIs for business workflows that benefit from fast iteration and simple deployment. The teams then connect those pieces with explicit contracts instead of splitting the whole backend by language preference.

Scalability also needs a more precise definition. Engineers scale throughput, team autonomy, release speed, or fault isolation. A service split can improve one and damage another. A cache service can reduce database load. A dozen small services can slow release work if each product change requires coordinated deployments.

The trade-off shows up in tests. A monolith needs unit tests and integration tests around shared modules. A microservice system needs those tests plus contract tests, environment parity, fixture management, and failure simulation. Engineers should price that work before they cut a new service.

McCracken’s post gives readers a useful prompt: Rust and Go can handle serious backend work, but language choice cannot rescue a weak architecture. Teams should start with the product behavior, the data model, and the failure mode. Then they can pick Rust, Go, REST, gRPC, queues, or a monolith with intent.

A small number of services with clear owners beats a fleet of thin wrappers around one workflow. The best backend teams use microservices where the boundary pays for its own complexity.