A plataforma sem servidor da Databricks inicia dezenas de milhões de VMs diariamente em AWS, Azure e GCP. Cada uma requer configuração de rede: destinos de armazenamento, private endpoints e permissões do Unity Catalog. Bilhões de solicitações de config por dia atingem esse gargalo na inicialização. Respostas síncronas não escalam mais.
O design original encadeava serviços no caminho crítico: o serviço de configuração de rede chamava Unity Catalog, armazenamentos de política de rede e Delta Sharing, agregava resultados e retornava a config montada. Com múltiplos serviços em série, a latência p99 RPC atingiu 5.000 ms. A disponibilidade degradava com cada dependência. Agregação multi-serviço repetida por workspace a cada inicialização, duplicando trabalho conforme a contagem de tenants crescia.
A rearquitetura divide o problema em dois caminhos. O caminho de gerenciamento funciona assincronamente: serviços upstream emitem eventos de mudança para uma fila de mensagens quando clientes modificam uma política de rede, adicionam uma conexão Unity Catalog ou alteram a configuração de Delta Sharing. Um processador de eventos consome esses eventos, determina workspaces afetados e distribui notificações de atualização por workspace. Um gerenciador de eventos local busca detalhes, recomputa a config completa do workspace e escreve em um armazenamento de snapshots local-partição. Um reconciliador re-sincroniza independentemente todos os workspaces em background como rede de segurança, garantindo consistência eventual mesmo quando eventos são perdidos ou reproduzidos fora de ordem.
O caminho de servimento lê do armazenamento. Quando um cluster inicia, o serviço de config de rede puxa o snapshot pré-computado com zero chamadas upstream. Esse desacoplamento—computação async, servimento de leitura síncrona—elevou disponibilidade para 99,99% e cortou volume de chamadas upstream em 86%. Em latência, o post Databricks apresenta duas figuras: o corpo narrativo afirma que p99 caiu de 5.000 ms para 125 ms (redução de 97,5%), enquanto a chamada introdutória afirma 75 ms (redução de 98,5%). Isso provavelmente reflete janelas de medição diferentes ou estágios de rollout. A melhoria de ordem de magnitude se mantém de qualquer forma.
Três decisões de design importam mais para times construindo sistemas análogos. Primeiro: eventos carregam apenas identificadores de workspace e recurso, não a própria payload de config. Eventos leves livres de dados sensíveis são seguros para enfileirar, reproduzir e reordenar sem introduzir uma superfície de exfiltração de dados. Segundo: armazenamentos de snapshots são local-partição, colocalizados com os workspaces que servem. Isso contém raio de explosão durante incidentes e elimina dependências cross-partition no caminho quente. Terceiro: estabilidade estática—durante outages upstream, o caminho de servimento retorna o último snapshot conhecido-bom em vez de falhar aberto ou fechado. Clusters iniciam; workloads executam; o incidente fica contido ao plano de gerenciamento.
O reconciliador é a diferença entre "eventualmente consistente com drift finito" e "consistente apenas se nenhum evento for jamais perdido." Re-sincronização completa periódica é operacionalmente cara mas barata comparada com bugs silenciosos de inconsistência que emergem apenas em falhas. Databricks trata o reconciliador como obrigatório, não opcional.
Para líderes de plataforma ML, o padrão se aplica diretamente. Endpoints de model serving requerem a mesma config na inicialização: quais endpoints de feature store são alcançáveis, que políticas de auth se aplicam, quais versões de modelo roteiam para essa réplica. Chamadas síncronas para um model registry no caminho quente de inferência é o mesmo anti-padrão que Databricks eliminou. Pré-computação de snapshots com invalidação event-driven apoiada por um reconciliador é a arquitetura apropriada para config que muda infrequentemente mas deve ser servida em altas taxas de requisição com baixa latência e alta disponibilidade. A redução de 86% em volume de chamadas upstream é o número para levar a conversas de planejamento de capacidade.