Databricks Lakebase Elimina Picos de Latência 10× na ERGO Hestia

A ERGO Hestia transferiu sua pilha de preços de seguros de 100-modelos para o Databricks Lakebase e Mosaic AI Model Serving Endpoints, resolvendo problemas com picos de latência na janela de lote e restrições de implantação fora do pico que antes impediam a cobrança B2C em tempo real. A plataforma da seguradora polonesa, que depende de mais de 1.000 variáveis para cotações em nível de milissegundos, antes canalizava dados através de um pipeline Delta para o Azure PostgreSQL, um adaptador de cache personalizado e, finalmente, para o aplicativo do motor de preços.

Este processo de várias etapas resultou em três restrições de produção: governança e linhagem foram divididas entre Databricks e PostgreSQL, complicando a capacidade de auditoria; as atualizações do modelo exigiam janelas de implantação fora do pico para evitar a desestabilização da camada de adaptador externo; e grandes ingestões de dados causavam picos de latência de 10× a 20× na camada de serviço externo, exigindo atualizações na janela de lote e impedindo ajustes de preços no mesmo dia.

A nova arquitetura mantém dados e serviço dentro do lakehouse. O Lakebase oferece uma camada transacional relacional em cima das tabelas Delta, com Sync Tables sincronizando dados processados para a camada de serviço sem extração manual. Os Mosaic AI Model Serving Endpoints expõem os resultados diretamente para o motor de preços por meio de API, eliminando o aplicativo intermediário e o banco de dados externo. O Unity Catalog gerencia tanto a linhagem de dados quanto de modelo, preservando conjuntos de treinamento históricos e versões do modelo para atender aos requisitos de auditoria de seguros poloneses.

O estudo de caso não fornece especificações operacionais. Ele menciona um pico de latência de 10×–20× como um problema herdado, mas não fornece benchmarks p50 ou p99 para a nova pilha, nem lista tipos de instância, horas de GPU ou custos por inferência. Alega envio de modelo mais rápido e resposta ao mercado instantânea, mas não fornece métricas de frequência de implantação ou reduções de prazo. As únicas métricas de escala concretas fornecidas são os mais de 100 modelos e mais de 1.000 variáveis; a latência em nível de milissegundos permanece um alvo, não uma figura verificada. As alegações de desempenho e velocidade devem ser consideradas direcionais até que haja telemetria de produção independente disponível.

O esforço de migração do Azure PostgreSQL e código de adaptador personalizado para o Lakebase não é quantificado em horas de engenharia ou tempo de inatividade, e o risco de regressão ao mover 100 modelos de uma camada de cache personalizada não é examinado. Substituir um banco de dados externo por Sync Tables e Model Serving Endpoints gerenciados pelo Databricks introduz novos limites de fornecedor, e os modos de falha da sincronização não são caracterizados. Para equipes fora do ecossistema do Databricks, replicar este padrão requer a importação do modelo de governança do Unity Catalog ou a construção de uma ponte de auditoria equivalente, um custo de integração não abordado no estudo de caso. A arquitetura é descrita como posicionando a equipe para cobrança B2C em tempo real, mas não está claro se ela está atualmente em produção.

O que um arquiteto pode considerar adotar: substituindo cadeias de serviço de extração-transformação-carregamento fragmentadas por uma camada relacional gerenciada co-localizada no lakehouse e fronteada por pontos de extremidade de modelo diretos, desde que o limite de serviço do fornecedor e o quadro de conformidade estejam alinhados com os primitivos de auditoria do catálogo.