Data ownership
- Each service owns its tables; others read through its API or its events
- No shared schema and no joins across services
- Read models built from events for screens that need data from several services
Microservices Consulting
Microservices architecture consulting
Splitting a monolith too early creates a distributed monolith that is harder to change than the original. Agnotic Technologies helps teams decide whether to split, draws service boundaries from the business, and builds the data, messaging, tracing and security patterns the split depends on.
Split or not decisionBoundaries from the domainSagas and outboxTracing across services
Trusted by global innovators
Microservices
What does microservices consulting cover?
Microservices consulting is architecture advice and hands-on engineering for teams deciding whether to break a monolith into independently deployed services. Agnotic Technologies reviews your codebase, teams and release pain, recommends a monolith, a modular monolith or microservices, and then builds the boundaries, data ownership and messaging patterns that choice needs.
Most of the value is in the decision. A single small team with one product rarely needs many services, while several teams queuing behind one deploy pipeline often do.
This page covers how to split and what changes after the split. Kubernetes operations, clusters and pipelines sit with our DevOps services.
Decision table
Which signals justify microservices, and which point to a modular monolith?
We fill this in with your engineering leads during the readiness review. More than one row usually applies.
| Signal you see | Shape we usually recommend | Why |
|---|---|---|
| One team, one product, releases are not blocked | A monolith, kept well structured | Services would add network calls, deploys and on-call load with no team to own them |
| Several teams change the same codebase and queue for one release | Microservices along team boundaries | Independent deploys remove the queue, as long as each team owns its service and its data |
| One part needs far more compute than the rest, such as search or media processing | Extract that one service | Scaling one hot path is cheaper than scaling everything; the rest can stay together |
| A sensitive area needs stricter access control and audit | A separate service for that area | A smaller boundary is easier to restrict, log and audit than a whole application |
| Modules share one schema and join across each other's tables | A modular monolith first | Splitting before data ownership is untangled creates a distributed monolith |
| Boundaries still move every few months | A modular monolith first | Moving a boundary inside one codebase is a refactor; between services it is a migration |
If the main complaint is a slow build or tangled code, fix the build and the module structure first. Microservices repair neither.
After the split
What changes in data, transactions and operations after the split?
The parts of a microservices design that cause most production incidents, and the patterns we use for each.
Transactions across services
- Sagas with a compensating step for each action
- Orchestrated sagas when a flow has many steps and needs one owner
- Choreographed sagas for short flows between two or three services
- A transactional outbox so a database change and its event never drift apart
Communication
- Synchronous APIs only where the caller needs an answer now
- Events for everything that can happen later
- Timeouts, retries with backoff and circuit breakers on every call
- Idempotent handlers, because messages can arrive twice
Observability
- OpenTelemetry traces, metrics and logs from every service
- W3C Trace Context headers carried through calls and messages
- One trace per user request across every service it touched
Service-to-service security
- Workload identity and mutual TLS between services
- Authorization checked in each service, not only at the gateway
- A service mesh once the number of services justifies it
Microservices on AWS
Which AWS services run each part of a microservices system?
AWS microservices architecture maps each concern to a service family: ECS on Fargate, EKS or Lambda for compute; ALB or API Gateway for synchronous calls; SQS, SNS or EventBridge for events; Step Functions for sagas; DynamoDB or Aurora per service; CloudWatch, X-Ray and AWS Distro for OpenTelemetry for tracing. Agnotic Technologies chooses per service, not per system.
| Concern | AWS options | What decides between them |
|---|---|---|
| Compute per service | Amazon ECS on AWS Fargate, Amazon EKS, AWS Lambda | Fargate for containers without servers or a Kubernetes control plane to run; EKS when the team already runs Kubernetes; Lambda for short, event-driven or spiky work |
| Synchronous calls | Application Load Balancer, Amazon API Gateway | A load balancer for traffic inside your network; API Gateway when callers need keys, throttling or request validation at the edge |
| Asynchronous events and queues | Amazon SQS, Amazon SNS, Amazon EventBridge | SQS when one consumer works through a queue; SNS to fan one message out to many; EventBridge to route events between services by their content |
| Workflows and sagas | AWS Step Functions | Orchestrated sagas whose steps, retries and compensations should sit in one visible definition; short choreographed flows stay on events |
| Data per service | Amazon DynamoDB, Amazon Aurora | DynamoDB for known key-based access patterns; Aurora when the service needs relational queries and transactions |
| Tracing and logs | Amazon CloudWatch, AWS X-Ray, AWS Distro for OpenTelemetry | OpenTelemetry instrumentation keeps traces portable; CloudWatch and X-Ray store and show them on AWS |
For the split itself we follow AWS Prescriptive Guidance on decomposing monoliths into microservices. Designs built only from functions and managed events are covered on our serverless development page.
Failure points
Why do microservices migrations stall?
The problems we are usually called in to fix, and what we change.
Challenge
Services share a database, so every schema change needs several teams to agree.
Agnotic approach
We split data ownership first, behind the existing code, before any service is deployed on its own.
Challenge
A user action spans four services and fails halfway.
Agnotic approach
The flow becomes a saga with compensating steps, and each step is safe to retry.
Challenge
Events are published after the commit, and some are lost when a service crashes.
Agnotic approach
A transactional outbox writes the event in the same transaction as the data, and a relay publishes it.
Challenge
Nobody can tell which service made a request slow.
Agnotic approach
Trace context is propagated through every call and message, with traces sampled at the edge.
Challenge
New services call each other in long synchronous chains.
Agnotic approach
We redraw boundaries around business capabilities and move work that can wait onto events.
Challenge
The big rewrite never catches up with the old system.
Agnotic approach
We extract one capability at a time behind a routing layer, the strangler fig approach, and retire old code as traffic moves.
SOA and ESB estates
How do you move from SOA or an ESB to microservices?
Many enterprise estates already have services, but routing, transformation and business rules live in a central bus. SOA consulting work with us moves that logic out step by step.
Map what the bus does
List every route, transformation, orchestration and business rule held in the ESB, with its owner and its traffic.
Move business rules into owning services
Rules that belong to a capability move into that capability's service, while the bus keeps only routing for now.
Replace orchestration with sagas or events
Long bus orchestrations become sagas owned by one service, or event flows between services.
Shrink the bus to an edge
What remains becomes an API gateway or a thin integration layer, and is retired wherever nothing depends on it.
Who it is for
Who asks us for microservices consulting?
Teams at the point where the shape of the system slows the business down.
Scale-ups with several teams on one codebase
Teams that queue behind each other's releases and want independent deploys.
Enterprises with SOA or ESB estates
Organizations whose business rules live in a central bus that few people can change.
Teams with a stalled migration
Projects halfway through a split, with shared databases and long synchronous call chains.
Startups planning for growth
A review that keeps the monolith modular, so a later split stays cheap.
Platforms with one hot path
Products where one capability, such as search or media processing, needs its own scaling.
Standards
Which standards and guidance do we design microservices to?
Published guidance behind the patterns on this page.
NIST SP 800-204NIST SP 800-204AW3C Trace ContextOpenTelemetryOpenAPIAsyncAPI
Facts and sources
Facts behind microservices architecture
Guidance from standards bodies and vendor documentation, each linked to its primary source.
NIST SP 800-204 lists the core features microservices need to interact securely, including authentication and access management, service discovery, secure communication protocols, security monitoring, circuit breakers, load balancing and throttling.
Source: NIST SP 800-204 (August 2019)NIST SP 800-204A names the service mesh as the best-known approach for specifying service-to-service security, resiliency and monitoring requirements uniformly and consistently across a microservices application.
Source: NIST SP 800-204A (May 2020)The W3C Trace Context specification defines standard HTTP headers and a value format for passing tracing context between services, so one request can be followed across a distributed system.
Source: W3C Trace ContextOpenTelemetry's default propagator uses the headers from the W3C Trace Context specification, carrying the trace ID and parent span ID in the traceparent header.
Source: OpenTelemetry documentation: context propagationAWS Prescriptive Guidance describes the transactional outbox pattern as the fix for dual writes, where one operation must update a database and send a message, and recommends idempotent consumers because duplicate messages can occur.
Source: AWS Prescriptive Guidance: transactional outbox pattern
Engagement
How does a microservices consulting engagement work?
Advice first, then engineering, then handover.
1.
Readiness review
We read the code, deploy history and incident log, talk to team leads and recommend a shape, in writing.
Assess2.
First extraction
Our engineers extract the first service with its data, events, tracing and security, alongside your team.
Build3.
Repeat and hand over
Each further extraction follows the same playbook, with your team leading more of the work each time.
ScaleScope and cost
What drives the cost of microservices consulting?
We do not publish prices. These are the factors we price on the scoping call.
Size and age of the codebase
How much code, how many modules and how clear the current structure is.
Data entanglement
How many tables are shared across modules and how many reports join across them.
Number of teams
How many teams will own services, and how their work splits today.
Integration estate
An ESB, partner integrations and batch interfaces that must keep working during the move.
Platform readiness
Whether CI/CD, containers, secrets and observability already exist for new services.
Compliance boundaries
Areas that need separate access control, audit logging or data residency.
Frequently Asked Questions
We do not publish prices. A readiness review is a fixed piece of work; extraction work depends on codebase size, data entanglement, team count and platform readiness. The scoping call ends with a written proposal for the review and the first extraction.
Usually not. A startup's boundaries change as it learns its market, and a well structured monolith lets it move them cheaply. We set up module boundaries so a later split, if it comes, follows lines that already exist.
One deployable application divided into modules with clear interfaces and their own data, where modules cannot reach into each other's tables. It gives most of the design benefits of services without the network, deploy and operations cost.
With sagas: each service commits its own step and publishes an event, and a failed step triggers compensating actions for the steps before it. We pair sagas with a transactional outbox so no event is lost.
Not to start. Many teams run a handful of services on a managed container service. A mesh earns its place when service-to-service security and traffic rules become hard to manage service by service.
Yes. Most engagements pair our engineers with your architects and team leads, and the written decision records, playbooks and diagrams stay with your team.