Notification Service consumindo pagamentos

Objetivos

• Consumir payment.approved e payment.failed no Sinatra
• Mapear evento para template de notificação
• Persistir histórico de envio para consulta

Pré-requisitos

• Eventos de pagamento já publicados
• notification-service com /health
• Kafka disponível no ambiente

Conceito

Notificação é efeito colateral de um fato de negócio, não parte do processamento principal de pagamento. Por isso, ela deve ser assíncrona e resiliente. Se o canal de notificação falhar, o pagamento não pode ser revertido por causa disso.

Ao consumir payment.approved e payment.failed, o Notification transforma evento técnico em comunicação de produto. Essa tradução deve ser explícita por template, para manter consistência de mensagem e facilitar manutenção.

Nesta aula, você implementa o consumidor Ruby, os templates de mensagem e uma API de consulta de notificações processadas.

Estrutura de arquivos

services/notification-service/
  app.rb
  app/consumers/payment_consumer.rb
  app/templates/payment_templates.rb
  app/repository/notification_repository.rb

Passo a passo

1. Criar templates em Ruby (app/templates/payment_templates.rb)

module PaymentTemplates
  def self.approved(customer_id, order_id)
    "Cliente #{customer_id}, seu pagamento do pedido #{order_id} foi aprovado."
  end

  def self.failed(customer_id, order_id, reason)
    "Cliente #{customer_id}, o pagamento do pedido #{order_id} falhou: #{reason}."
  end
end

2. Criar repositório em memória (app/repository/notification_repository.rb)

class NotificationRepository
  def initialize
    @items = []
  end

  def save(notification)
    @items << notification
  end

  def all
    @items
  end
end

3. Criar consumidor Kafka (app/consumers/payment_consumer.rb)

require "json"
require "kafka"
require_relative "../templates/payment_templates"

class PaymentConsumer
  def initialize(repository)
    @repository = repository
    @kafka = Kafka.new(["kafka:9092"], client_id: "notification-service")
  end

  def start
    consumer = @kafka.consumer(group_id: "notification-payment-group")
    consumer.subscribe("payment.approved.v1")
    consumer.subscribe("payment.failed.v1")

    consumer.each_message do |message|
      event = JSON.parse(message.value)
      content = if message.topic == "payment.approved.v1"
        PaymentTemplates.approved(event["customerId"], event["orderId"])
      else
        PaymentTemplates.failed(event["customerId"], event["orderId"], event["reasonCode"])
      end

      @repository.save({
        id: "not-#{Time.now.to_i}",
        topic: message.topic,
        customerId: event["customerId"],
        orderId: event["orderId"],
        message: content
      })
    end
  end
end

4. Expor endpoint de consulta no app.rb

require "sinatra"
require "json"
require_relative "app/repository/notification_repository"

repo = NotificationRepository.new

get "/notifications" do
  content_type :json
  repo.all.to_json
end

Como testar

1. Subir ambiente:

docker compose -f infra/docker-compose.yml up --build -d kafka payment-service notification-service

2. Gerar evento aprovado (via payment API):

curl -s -X POST http://localhost:8080/payments \
  -H "Content-Type: application/json" \
  -d '{"orderId":"ord-301","customerId":"cli-301","amount":70.0,"currency":"BRL","simulate":"approved"}'

3. Consultar notificações:

curl -s http://localhost:4567/notifications

Saída esperada: lista com mensagem de aprovação.

4. Repetir com simulate:"failed" e validar mensagem de falha.

Dicas de projeto

• Separe template de consumo para facilitar manutenção.
• Mantenha estrutura de notificação com topic e orderId.
• Isole integração externa (e-mail, SMS) em adaptador próprio.
• Faça log de falhas de parsing e envio.

Erros comuns

• Processar evento sem validar campos obrigatórios.
• Misturar lógica de template com código de infraestrutura.
• Não persistir histórico de envio.
• Executar consumer no mesmo thread do servidor HTTP sem controle.

Resumo

O Notification Service agora consome eventos de pagamento e transforma resultados técnicos em mensagens de negócio. Com histórico e templates, o fluxo fica rastreável e pronto para evoluir para canais reais.