Microservice style

When to choose microservice style

The microservice model is the right choice when you have multiple teams that need to develop, deploy, and scale services independently. The central benefit is not technical — it is organisational: teams own their service end-to-end without coordinating deployments with every other team.

If you are a single team or the project is early-stage, start with the monolithic deployment. You can migrate to microservice style later without rewriting service code, because PURISTA service logic is independent of the deployment topology.

It’s a common approach to have a microservice architecture. We call it here microservice style, as classical microservices are typically (more or less) directly communicating via HTTP. In PURISTA, the communication is not a direct connection between two instances — it is done via a message broker. Because of this, service mesh software like Istio cannot be simply used. Here, you might want to consider Dapr.

This solution fits if you have multiple developer teams, which should be able to work (and scale) independently. This is the biggest PRO in comparison to the monolithic approach: It enables scaling the whole project and not only some software instances.

Bootstrap pattern

Each service runs in its own process, connected to a shared message broker. Only the bootstrap file changes — service code (commands, subscriptions, schemas) is identical to the monolithic deployment:

// src/index.ts — one process per service
import { NatsBridge } from '@purista/natsbridge'  // or AmqpBridge from '@purista/amqpbridge'
import { gracefulShutdown, initLogger } from '@purista/core'
import { orderV1ServiceBuilder } from './service/order/v1/orderV1ServiceBuilder.js'

const main = async () => {
  const logger = initLogger('info')

  const eventBridge = new NatsBridge({
    url: process.env.NATS_URL ?? 'nats://localhost:4222',
  })
  await eventBridge.start()

  const orderService = await orderV1ServiceBuilder.getInstance(eventBridge)
  await orderService.start()

  gracefulShutdown(logger, [eventBridge, orderService])
}

main()

Run a separate instance of this bootstrap for each service (Order, Payment, User, etc.), all pointing at the same broker URL. Services discover each other through the broker — no service mesh or sidecar required.

This solution will need the effort to set up, configure and maintain. You will also quickly hit the point, where you will need additional third-party solutions to handle the bigger complexity. Here, a common way is, the usage of kubernetes. These third-party solutions will also bring a lot of additional benefits. The range will be from “some nicer UI” up to “autoscaling services” and automated, reproducible deployment. The costs, for running a system this way, are (mostly) predictable - similar to the monolithic approach.

The overall workload is distributed across all running instances and the number of running instances per service can be set differently. If you have for example some service, which does some time-consuming computation, it might make sense to have more instances running.