Microservices Development: When to Use It and How to Do It Right

By Viprasol Tech Team

---

Microservices is one of the most misapplied architectural patterns in software development. The pattern makes genuine sense for specific problems: large codebases with multiple teams, services with dramatically different scaling requirements, and systems where independent deployment of components provides real operational value.

Applied to a startup's first product, it creates distributed systems complexity without the distributed systems scale that justifies it. The cost — in operational overhead, debugging complexity, and development velocity — is real and front-loaded. The benefits — independent scaling, technology flexibility, team autonomy — are only realized at a scale most applications never reach.

The most important question in microservices development is: should you actually be building microservices?

---

When Microservices Are Right (and When They Aren't)

Use microservices when:

• Multiple independent teams work on different parts of the system (Conway's Law: your architecture will reflect your team structure)
• Components have dramatically different scaling requirements (the payment service needs 10x more instances during sales events than the admin service)
• Services have different technology requirements (ML inference in Python alongside a Node.js API)
• Independent deployment of components is genuinely needed (you can deploy the notification service without touching the order service)
• The monolith has become an actual bottleneck — builds take 30 minutes, deploys take hours, teams block each other

Don't use microservices when:

• You're building v1 of a product (a monolith with clean internal boundaries is faster and simpler)
• You have fewer than 10 engineers (team structure doesn't support the ownership model)
• Your services would share a database (that's a distributed monolith, not microservices — the worst of both worlds)
• You're doing it because the job postings mention it

The recommended path: Start with a modular monolith. Extract services when specific pain points justify it. This is the "strangler fig" approach to service decomposition — incrementally, driven by actual need.

---

Decomposition Principles: How to Split Services

When microservices are genuinely warranted, the decomposition principle matters enormously. Wrong decomposition creates tight coupling that defeats the purpose.

Domain-driven decomposition (correct): Split along business capability boundaries. Each service owns its data, its business logic, and its API for that capability.

Order Service      → everything about orders (placement, status, history)
Inventory Service  → product stock, reservations, warehouse
Payment Service    → payment processing, refunds, billing
Notification Service → email, SMS, push notifications
User Service       → authentication, profile, preferences

Technical decomposition (incorrect): Splitting by technical layer (a "frontend service," a "database service," a "cache service") creates services that must coordinate on every request and can't be deployed independently.

Each service in a correctly decomposed system:

• Has its own database (no shared databases between services)
• Can be deployed independently without coordinating with other services
• Has a single, clear business responsibility
• Is owned by one team

---

Inter-Service Communication Patterns

Synchronous (HTTP/gRPC)

Use for queries where the response is needed immediately:

// Service-to-service HTTP with circuit breaker (using opossum)
import CircuitBreaker from 'opossum';

function createServiceClient(serviceUrl: string) {
  const options = {
    timeout:              3000,   // 3 second timeout
    errorThresholdPercentage: 50, // open circuit at 50% errors
    resetTimeout:         30000,  // retry after 30 seconds
  };

  const breaker = new CircuitBreaker(
    async (path: string, init?: RequestInit) => {
      const response = await fetch(`${serviceUrl}${path}`, init);
      if (!response.ok) throw new Error(`Service error: ${response.status}`);
      return response.json();
    },
    options
  );

  breaker.on('open',     () => console.warn(`Circuit OPEN for ${serviceUrl}`));
  breaker.on('halfOpen', () => console.info(`Circuit HALF-OPEN for ${serviceUrl}`));
  breaker.on('close',    () => console.info(`Circuit CLOSED for ${serviceUrl}`));

  return {
    get:  (path: string) => breaker.fire(path),
    post: (path: string, body: unknown) => breaker.fire(path, {
      method: 'POST',
      body:   JSON.stringify(body),
      headers: { 'Content-Type': 'application/json' },
    }),
  };
}

// Usage in Order Service
const inventoryClient = createServiceClient(process.env.INVENTORY_SERVICE_URL!);

async function checkInventory(productId: string, quantity: number): Promise<boolean> {
  try {
    const result = await inventoryClient.get(`/products/${productId}/availability?qty=${quantity}`);
    return result.available;
  } catch (err) {
    // Circuit is open or service unavailable — fail gracefully
    console.error('Inventory check failed:', err);
    return false;  // or throw, depending on whether inventory check is critical
  }
}

Asynchronous (Event-Driven)

Use for operations that don't need an immediate response — and should still happen even if the downstream service is temporarily unavailable:

// Publishing events to AWS SQS (with dead-letter queue)
import { SQSClient, SendMessageCommand } from '@aws-sdk/client-sqs';

const sqs = new SQSClient({ region: 'us-east-1' });

interface DomainEvent<T = unknown> {
  eventId:   string;
  eventType: string;
  version:   number;
  timestamp: string;
  sourceService: string;
  payload: T;
}

async function publishEvent<T>(event: Omit<DomainEvent<T>, 'eventId' | 'timestamp'>) {
  const fullEvent: DomainEvent<T> = {
    ...event,
    eventId:   crypto.randomUUID(),
    timestamp: new Date().toISOString(),
  };

  await sqs.send(new SendMessageCommand({
    QueueUrl:               process.env.EVENT_QUEUE_URL!,
    MessageBody:            JSON.stringify(fullEvent),
    MessageGroupId:         event.eventType,  // FIFO queue grouping
    MessageDeduplicationId: fullEvent.eventId,
  }));
}

// Order Service publishes an event when order is placed
await publishEvent({
  eventType:     'order.placed',
  version:       1,
  sourceService: 'order-service',
  payload: {
    orderId:    order.id,
    userId:     order.userId,
    items:      order.items,
    totalCents: order.totalCents,
  },
});

// Notification Service subscribes and sends confirmation email
// Inventory Service subscribes and reserves stock
// Analytics Service subscribes and records the event
// Each subscriber handles it independently — no direct coupling

---

API Gateway Pattern

Every microservices architecture needs a single entry point for external clients. The API gateway handles:

• Authentication and authorization (verify JWT before routing to any service)
• Rate limiting
• Request routing to the appropriate service
• Response aggregation (combining data from multiple services for one API call)

External Client (mobile app, web, third party)
    ↓
API Gateway (Kong / AWS API Gateway / custom)
    ├── /api/orders/*    → Order Service
    ├── /api/inventory/* → Inventory Service
    ├── /api/users/*     → User Service
    └── /api/payments/*  → Payment Service

AWS API Gateway with Lambda authorizer for JWT verification is a common pattern. For custom needs, Kong or Traefik work well.

---

Distributed Tracing: Essential for Debugging

Debugging a single failed request across 5 services without distributed tracing is nearly impossible. OpenTelemetry is the standard:

// OpenTelemetry setup in each service
import { NodeSDK }                from '@opentelemetry/sdk-node';
import { OTLPTraceExporter }      from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  serviceName:  process.env.SERVICE_NAME!,  // 'order-service', 'inventory-service', etc.
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT!,  // Jaeger, Tempo, or Datadog
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

// With this, every HTTP request, database query, and SQS message is traced
// automatically — you can see the full request path across all services

Every inter-service HTTP request automatically propagates the traceparent header, linking spans across services. A request that touches 5 services appears as one trace with 5 spans in Jaeger.

---

The Cost Reality of Microservices

Microservices add significant operational complexity:

Development overhead: Every new feature that spans services requires coordination, API contracts, and integration testing. What's one PR in a monolith is 3–5 PRs across services.

Infrastructure cost: Each service needs its own container instances, potentially its own RDS instance, its own load balancer. A 10-service application has 3–5x the infrastructure cost of an equivalent monolith.

Observability cost: Distributed tracing, centralized logging, and service mesh monitoring are more expensive and more complex than monolith monitoring.

Rough overhead estimate: For a team that would take 6 months to build a feature in a monolith, the same feature in microservices takes 8–10 months. That overhead is the price for the benefits — and it's only worth paying when the benefits (independent scaling, team autonomy, independent deployment) are genuinely needed.

---

Working With Viprasol

Our cloud architecture services and web development practice include microservices architecture design and implementation on AWS — including service decomposition, ECS/EKS deployment, event-driven integration, API gateway configuration, and distributed tracing.

We also have direct conversations about whether microservices are the right choice for your specific situation — and we'll recommend a modular monolith when that's the better answer.

Building microservices? Viprasol Tech designs and implements distributed systems for startups and enterprises. Contact us.

---

See also: AWS Consulting Company · Kubernetes Development · DevOps Consulting Company

Sources: Martin Fowler — Microservices · OpenTelemetry Documentation · AWS Microservices on ECS