Services That Scale
Independently. Teams That
Deploy Without Coordination.

Microservices are not the right choice for: early-stage startups with small teams (under 10 engineers), products with tight development timelines, systems where the domain boundaries are not yet understood, or teams with no experience operating distributed systems. A well-structured monolith is faster to build, easier to debug, and entirely capable of scaling to significant traffic. Naraway recommends starting with a modular monolith and migrating specific domains to services when team size, deployment frequency, or scaling requirements justify it.

The strangler fig pattern is the safest approach to migrating a monolith to microservices. Rather than a big-bang rewrite, new functionality is built as independent services while legacy functionality continues to run in the monolith. An API gateway routes requests to the new service or the monolith depending on the path. Over time, service by service, the monolith is strangled — replaced by microservices until it can be decommissioned. This approach allows incremental migration with rollback at each step.

A service mesh (Istio, Linkerd, Cilium) handles service-to-service communication — mutual TLS, load balancing, circuit breaking, retries, timeouts, and distributed tracing — without requiring application code changes. You need one when you have 10+ services communicating over the network, need mTLS for compliance, are doing canary deployments with precise traffic weighting, or need detailed inter-service latency observability. For fewer than 5-10 services, a well-configured API gateway is sufficient.

Event-driven architecture uses an event bus (Kafka, RabbitMQ, AWS EventBridge) where services publish events and subscribe to events from other services, rather than calling each other directly. EDA is better than REST when: you need temporal decoupling, you have multiple services reacting to the same event, or you need to replay historical events. REST is better for synchronous request-response flows where the caller needs an immediate answer. Most mature microservice architectures use both.

Distributed transactions cannot use traditional ACID database transactions because each service owns its own database. The two main patterns are: Saga (a sequence of local transactions with compensating transactions for rollback) and the Outbox Pattern (events written to an outbox table in the same local DB transaction, then published to the event bus reliably). Naraway implements the appropriate pattern based on your consistency requirements.