Jumentix
Blueprint SaaS distribuído

Escale serviços sem reescrever a comunicação

Use workers independentes e mediação baseada em contratos para mover requests em processo para RabbitMQ, BullMQ ou outro transporte.

Mascote open source do Jumentix

O que este blueprint entrega à sua equipe

  • Propriedade independente por serviço
  • Padrões request/response e publish/listen
  • Runtime, testes e deploy por serviço
bun run pm2:start:dev:restapi
bun run pm2:start:staging:restapi
bun run pm2:start:prod:restapi

Do zero ao primeiro MVP

Uma sequência prática de lançamento para este blueprint

Use este caminho quando o primeiro MVP já precisa de ownership independente ou uma capacidade background que não deve compartilhar o ciclo de vida da aplicação principal.

Extraia só um limite

Escolha um contexto delimitado ou comportamento worker, como notificação de task, analytics de category ou import assíncrono.

  • Escolha um comportamento worker: notificar o responsável quando uma task é criada.
  • Congele o subject versionado tasks.created.v1 e seu payload de exemplo.
  • Derive o tipo do payload do exemplo do contrato para produtor e worker compartilharem uma fonte.
  • Escreva critérios de aceite: produtor e worker importam apenas contracts.ts.

Saída MVP: um limite de serviço com subject e payload claros.

export const TaskCreatedEvent = {
  subject: 'tasks.created.v1',
  example: {
    id: 'task-1',
    title: 'Notify assignee',
    categoryId: 'work'
  }
} as const;

export type TaskCreatedPayload = typeof TaskCreatedEvent.example;

Critérios de pronto do primeiro MVP

  • Produtor e worker importam apenas contracts.ts — nunca um ao outro.
  • O mediator in-memory prova publish/subscribe antes de qualquer broker.
  • O worker roda sob perfil nomeado próprio e reinicia sem mudança no produtor.
  • Falha explícita: mensagem venenosa vai para a DLQ e o replay é medido.

Fora de escopo de propósito

  • Service mesh e tracing distribuído.
  • Múltiplos brokers ou migração de transporte.
  • Topologia de dead-letter além do primeiro retry explícito.
  • Extração de mais contextos delimitados.

Escopo MVP

Mantenha a primeira versão pequena o bastante para comprovar

Um limite de serviço

Extraia o menor comportamento com owner e contrato de mensagem claros.

Fatia de ownership

Um caminho durável

Adicione durabilidade de broker só após o contrato in-memory provar a interação.

Fatia de mensageria

Um gate independente

Rode testes e checks de deploy focados no limite extraído.

Fatia de governança
Área de provaPergunta a responderMecanismo JumentixEvidência MVP
CompatibilidadeProdutor e consumidor evoluem sem importar um ao outro?Testes de contrato de mensagem e exemplos de subject/payload.O contrato controla compatibilidade.
IsolamentoO serviço pode falhar sem esconder a falha?Retry, contrato de erro, dead-letter ou evidência de fallback.O modo de falha é explícito.
OwnershipUm time consegue publicar o serviço sozinho?Perfil, testes e evidência de release por serviço.Ownership independente é real, não teatro organizacional.

Implementação prática

Código completo para a primeira fatia funcional

Estes exemplos mantêm Category e Task como vocabulário de produto e mostram controller, contrato, client, worker ou camada de estado necessários para chegar a um MVP executável.

export const TaskCreatedEvent = {
  subject: 'tasks.created.v1',
  example: {
    id: 'task-1',
    title: 'Notify assignee',
    categoryId: 'work'
  }
} as const;

export type TaskCreatedPayload = typeof TaskCreatedEvent.example;

Construa o produto. Preserve a arquitetura.

Explore o código, execute a fábrica localmente e transforme seu próximo serviço Node.js em uma capacidade repetível de plataforma.