Skip to main content

Resiliência e Disponibilidade

  1. Existe um SLA (acordo de nível de serviço) para a plataforma Carol?
  2. Onde acompanho a disponibilidade da plataforma?
  3. Como a plataforma evita a perda de registros recebidos pela API?
  4. O que acontece se a plataforma estiver indisponível no momento do envio?
  5. Quais mecanismos de redundância e backup a plataforma possui?
  6. Como os serviços e dados são recuperados em caso de incidente?
  7. Qual a responsabilidade dos aplicativos que enviam dados para a Carol?

1. Existe um SLA (acordo de nível de serviço) para a plataforma Carol?​

A plataforma Carol é hospedada no Google Cloud Platform (GCP), que é o provedor de infraestrutura da Carol. Dessa forma, os níveis de serviço adotados pela plataforma seguem os SLAs publicados pelo Google Cloud para os serviços utilizados.

→ Veja os SLAs do Google Cloud.

Entre os principais serviços do Google Cloud utilizados pela plataforma Carol estão:

2. Onde acompanho a disponibilidade da plataforma?​

A disponibilidade dos principais recursos da plataforma (Carol API, Carol APP, Data Ingestion, Data Processing, Data Subscription e serviços do Google Cloud) é publicada em https://status.carol.ai/, com histórico diário dos últimos 90 dias, métricas de tempo de resposta e taxa de erro, e o histórico de incidentes.

→ Veja mais informações na seção Status da Carol.

3. Como a plataforma evita a perda de registros recebidos pela API?​

O fluxo de ingestão foi desenhado para que um registro só seja confirmado ao cliente depois de estar armazenado de forma persistente:

  1. Confirmação somente após persistência na fila: a API de ingestão só retorna sucesso após o registro ser aceito por uma fila de mensagens persistente. Caso a fila não confirme o recebimento, a API retorna erro ao cliente.
  2. Entrega garantida no processamento: um registro só é removido da fila depois de ter sido encaminhado com sucesso para a etapa seguinte (Google Pub/Sub). Se ocorrer uma falha ou reinício de serviço antes disso, o registro permanece na fila e é processado novamente de forma automática.
  3. Armazenamento na Staging Area: os registros são gravados na Staging Area, armazenada no BigQuery.
  4. Dados imutáveis: os registros armazenados na Carol são imutáveis. Quando um registro é atualizado, a plataforma preserva as versões anteriores até que o processo de consolidação seja executado.
Nota

A API de ingestão é assíncrona: o retorno HTTP 200 indica que o registro foi recebido e persistido na fila de ingestão, mas alguns segundos podem ser necessários até que ele esteja disponível na staging table ou no data model.
→ Veja mais detalhes em Enviando dados.

4. O que acontece se a plataforma estiver indisponível no momento do envio?​

Se a plataforma não conseguir persistir o registro, a API de ingestão retorna um erro (por exemplo, HTTP 5xx) e o registro não é considerado recebido. Da mesma forma, quando o limite de requisições é excedido, a API retorna HTTP 429 com o cabeçalho Retry-After.

Nesses cenários, o aplicativo ou conector de origem deve manter o registro e reenviá-lo posteriormente. Veja a pergunta 7.

5. Quais mecanismos de redundância e backup a plataforma possui?​

  • Infraestrutura em nuvem: a plataforma é hospedada no Google Cloud Platform (GCP), com dados e servidores localizados nos Estados Unidos, utilizando serviços gerenciados que armazenam os dados de forma redundante (BigQuery e Pub/Sub).
  • Criptografia: os backups são armazenados em buckets do Google com criptografia na camada de armazenamento.

→ Veja também: Segurança.

6. Como os serviços e dados são recuperados em caso de incidente?​

  • Serviços: os serviços da plataforma possuem verificações de saúde (health checks), reinício automático de processos e retentativas com backoff nas integrações com os serviços do Google Cloud.
  • Registros em processamento: registros que estavam sendo processados durante uma falha ou reinício de serviço permanecem na fila e são processados novamente de forma automática.
  • Reenvio de registros: a plataforma dispõe de mecanismo para reenviar registros recebidos pela camada de ingestão, com retentativas e controle de ponto de retomada (checkpoint).
  • Comunicação: incidentes e ações tomadas são publicados em https://status.carol.ai/ e no Histórico de Comunicados.

7. Qual a responsabilidade dos aplicativos que enviam dados para a Carol?​

A garantia de não perda de registros de ponta a ponta é compartilhada entre a plataforma e o aplicativo que envia os dados. Recomenda-se que os aplicativos e conectores:

  • Considerem um registro como entregue somente após receber retorno de sucesso (HTTP 2xx) da API de ingestão.
  • Armazenem localmente os registros não confirmados e os reenviem em caso de erro, timeout ou indisponibilidade de rede.
  • Implementem retentativas com backoff exponencial e respeitem o cabeçalho Retry-After em respostas HTTP 429.
  • Utilizem um crosswalk estável, garantindo que reenvios atualizem o mesmo registro em vez de gerar duplicidade.