pulse

/projects/kota-embed

← Todos os projetos

Kota Embed

Adesão a plano de saúde, embutida dentro das plataformas de outras empresas.

Senior Product Engineer, time de plataforma · Trabalho profissional

.NETPostgreSQLEF CoreAWSOpenTelemetryMulti-tenantWebhooks
WebsitePrivado
Captura de tela de Kota Embed

Visão geral

O Kota Embed permite que empregadores ofereçam plano de saúde aos funcionários sem sair do software que já usam — o fluxo de adesão roda embutido numa plataforma de terceiro, apoiado por um serviço .NET multi-tenant que integra direto com as seguradoras.

O que eu fiz

O núcleo multi-tenant foi meu — a parte que transforma um pedido de adesão numa apólice, através de nove seguradoras que se comportam de formas diferentes.

  • As máquinas de estado de intent por trás de adesão, cotação, alteração e renovação.
  • Requisitos adaptativos: perguntar a um serviço o que um caso precisa coletar, em vez de codificar um formulário por seguradora.
  • O contrato versionado da API pública e seus webhooks.
  • Contratos de provedor introduzidos atrás de feature flags e migrados sem parar o produto.
  • Idempotência e supressão de duplicatas, e a suíte de integração que cobre as duas.

O front-end — o fluxo embutido e seu SDK — foi feito por outros; não tenho commits nele.

O problema

Inscrever alguém num plano de saúde parece um formulário. Não é. Cada seguradora quer dados diferentes, em formato diferente, no tempo dela; umas respondem por HTTP, outras trocando arquivos por SFTP. As obrigações regulatórias de disclosure mudam conforme a região. E tudo isso acontece dentro de um iframe hospedado na plataforma de outra empresa, onde o usuário espera que seja imediato. Um formulário hardcoded por seguradora não sobrevive à segunda seguradora.

Em números

9integrações de seguradoraAPIs HTTP e troca de arquivos por SFTP
3regiões regulatóriasas regras de disclosure mudam por região
7tipos de fluxo de intentadesão, cotação, alteração, renovação…

Arquitetura

Um monólito modular em .NET dividido por contexto delimitado: o núcleo multi-tenant da plataforma, um módulo por seguradora, mais compliance, webhooks e relatório financeiro. O núcleo nunca chama uma seguradora direto — toda chamada a provedor passa por uma adapter factory, então o código que roda uma adesão não sabe com qual seguradora está falando. Trabalho de longa duração é modelado como intent: uma máquina de estados persistida, e não uma requisição mantida aberta.

  1. Third-party platformA aplicação hospedeira, embutindo o fluxo de adesão num iframe.
  2. Public APIContrato versionado e webhooks assinados para as plataformas que embutem o fluxo.
  3. Platform coreEmpregadores, funcionários, elegibilidade e as máquinas de estado dos intents.
  4. Adapter factoryA única porta para cada seguradora, mantendo o núcleo agnóstico de provedor.
  5. Insurer integrationsUm módulo por seguradora, por HTTP ou troca agendada de arquivos via SFTP.

A vida de uma adesão

Estes são os status pelos quais uma adesão realmente passa. Ela também pode terminar inelegível, ou nem ser realizada — o caminho feliz abaixo não é a única saída.

  1. ProcessingO pedido é registrado sob sua chave de idempotência e validado, antes de qualquer chamada externa.
  2. ActionRequiredFalta algo que só uma pessoa pode fornecer. O intent declara isso e espera, em vez de falhar.
  3. PendingConfirmationTudo o que a seguradora e a região exigem está reunido; quem pediu confirma antes do envio.
  4. EnrollingEntregue à seguradora pelo adapter dela, que responde no tempo dela.
  5. EnrolledA apólice existe. A plataforma reporta de volta a quem pediu.

O que faz

  • Multi-tenant por construção: plataforma → empregador → funcionário → grupo, isolados por tenant.
  • Configuração de grupo, adesão, cotação, alteração, renovação, importação de apólice e gestão de dependentes, cada uma como seu próprio fluxo.
  • Elegibilidade calculada a partir das regras do provedor, em vez de guardada como flag.
  • Dados de apólice e plano agregados entre seguradoras numa resposta única.
  • Uma API pública versionada e webhooks assinados para as plataformas que embutem o fluxo.
  • Integrações de seguradora tanto por API HTTP quanto por troca agendada de arquivos via SFTP.

Decisões de engenharia

  • Intent em vez de request/response

    Uma adesão não termina dentro de uma chamada — uma seguradora pode levar minutos ou dias. Modelar isso como máquina de estados persistida, com status próprio, transforma o estado intermediário em algo que o sistema consulta, retoma e reporta, em vez de uma transação mantida aberta na esperança.

  • Requisitos adaptativos em vez de um formulário por seguradora

    O que um caso precisa coletar depende da seguradora e da região regulatória ao mesmo tempo. Em vez de codificar nove formulários, a plataforma pergunta a um serviço de requisitos o que aquele caso exige e renderiza isso. Adicionar uma seguradora deixa de ser mudança de front-end. A consulta acontece atrás da mesma fronteira de adapter, então o núcleo continua sem manipular a identidade de nenhum provedor.

  • Uma adapter factory como única porta para o provedor

    O núcleo da plataforma resolve um adapter e fala com ele. Nunca fica sabendo qual seguradora está atendendo, e é isso que impede uma décima integração de tocar na lógica de adesão — e o que permitiu introduzir contratos de provedor atrás de feature flags e migrar sem parar o produto.

  • Idempotência e supressão de duplicata como requisito, não conserto

    Retry acontece, webhook chega duas vezes e consumidores rodam concorrentes sobre as mesmas linhas. A criação de intent aceita chave de idempotência, a adesão automática suprime o par intent-e-webhook duplicado, e o consumer de triagem de elegibilidade trata conflito de serialização em vez de assumir que ele não ocorre.