O Que É Preciso para Ligar uma Plataforma a Outra Coisa

Duas formas de interface, usadas para coisas diferentes

A interface de programação de uma corretora costuma vir em duas formas. Uma responde a uma pergunta de cada vez que lhe é feita e nada diz no intervalo: sai um pedido, volta uma resposta, e até ao pedido seguinte nada mais se sabe. A outra mantém uma ligação aberta e envia atualizações à medida que acontecem, pelo que a informação chega sem ser pedida.

As corretoras oferecem habitualmente as duas, e não são alternativas no sentido em que uma lista de opções o sugere. Respondem a perguntas diferentes. Tudo o que precisa de uma resposta definida sobre uma coisa concreta num momento concreto — o estado desta ordem, o que a conta tem neste momento — é uma pergunta, e as perguntas pertencem à primeira forma. Tudo o que precisa de saber à medida que as coisas mudam pertence à segunda.

A consulta repetida tem um chão por onde não passa

Pedir um preço repetidamente em vez de o subscrever dá uma imagem que nunca é mais fresca do que o intervalo entre pedidos. Reduzir o intervalo a metade reduz a desatualização a metade e duplica o número de pedidos, e há um ponto a partir do qual a corretora não aceita esse número. Existe portanto um chão por baixo do quão atual pode ser uma imagem obtida assim, e onde esse chão fica é decidido por outra pessoa.

Isto importa mais do que parece, porque a desatualização viaja. Qualquer decisão, qualquer apresentação, qualquer comparação feita a partir de um valor obtido por consulta herda a idade desse valor sem levar consigo uma etiqueta que o diga. Um sistema que consulta e depois age está a agir sobre um número cuja idade normalmente não escreveu em lado nenhum.

Um limite é, em regra, vários limites

Um limite de frequência é um teto ao número de pedidos que uma conta pode enviar dentro de um período, e raramente é um número só. Pontos de acesso diferentes são contados em separado, e a permissão para ler preços não costuma ser a permissão para enviar ordens. Um sistema dimensionado pelo limite generoso pode ser recusado pelo limite estrito, e será recusado no momento menos conveniente, porque o tráfego de ordens tende a concentrar-se exatamente quando o tráfego de preços se concentra.

Que limites se aplicam e como são contados está documentado pela corretora e não se descobre por experiência. Encontrar a parede andando contra ela é gastar recusas para saber onde ela está, numa conta real, no momento em que a caminhada calhar acontecer.

A maneira cara de lidar com uma recusa

Repetir de imediato agrava um limite de frequência, porque as repetições também são contadas, e um sistema que responde a ser travado tentando com mais força trava-se ainda mais. Recuar em vez de empurrar é a totalidade do comportamento correto aqui, e é pouco intuitivo precisamente porque a maioria das outras falhas recompensa a insistência.

O problema mais sério é que uma recusa nem sempre se distingue de outras falhas. Um pedido que expirou do lado do cliente pode na mesma ter sido recebido e executado, e tratar a ausência de resposta como ausência de ordem é a forma de um sistema enviar a mesma ordem duas vezes. Tudo o que negoceia através de uma interface tem de estabelecer o que aconteceu de facto, relendo a conta, antes de voltar a agir. Isso é uma operação diferente de repetir, e é a que tem de vir primeiro.

Um fluxo que está aberto e calado

O fluxo contínuo remove o chão da consulta repetida e traz o seu próprio trabalho em troca. As ligações caem e têm de ser restabelecidas. As atualizações perdidas durante a queda têm de ser recuperadas de algum lado, o que normalmente quer dizer pedir o estado atual à interface do outro tipo em vez de assumir que o intervalo não continha nada.

A falha difícil não é nenhuma dessas. É uma ligação que continua aberta e deixou de entregar, e que parece exatamente um mercado calmo — porque um mercado calmo também não entrega nada. Examinar o conteúdo do que chegou não os separa, já que em ambos os casos não chegou nada. O que os separa é o tempo: a idade da última mensagem e não o que ela trazia. Um programa que consome um fluxo precisa de algo que envelheça por si e o diga, ou lerá uma ligação morta como condições calmas durante todo o tempo que a condição durar.

Um alerta enviado para um endereço é de sentido único

Um alerta por endereço web é a plataforma a enviar uma mensagem para um endereço que o leitor fornece quando uma condição definida num gráfico se verifica, em vez de — ou além de — a mostrar no ecrã. É a ponte habitual entre a análise num sítio e a ação noutro, e o apelo é evidente: uma condição expressa num gráfico passa a ser entrada de outro programa.

O que vale a pena compreender é que é enviar e esquecer. O emissor fica em geral a saber se a mensagem foi aceite e absolutamente nada sobre o que foi feito com ela. As entregas podem chegar tarde, fora de ordem, ou mais do que uma vez. Uma mensagem que falha pode ou não ser repetida, e essa política é do emissor e não do leitor. Nada disto faz do mecanismo um mau mecanismo. Faz dele um mecanismo cujas garantias são mais fracas do que parecem, e assumir as mais fortes é como se instala uma falha silenciosa logo no início.

O endereço não é uma credencial

Quem recebe não tem maneira de saber quem lhe enviou um pedido, a não ser que o pedido o prove. O endereço é portanto a única coisa entre o alerta e qualquer outra pessoa que venha a saber o endereço, e os endereços escapam pelas vias mais banais: colados num pedido de apoio, copiados para um documento partilhado, deixados à vista numa captura de ecrã.

Um recetor que age sobre o que chega tem portanto duas obrigações, e ambas decorrem de tudo o que ficou dito acima. Tem de autenticar a mensagem em vez de confiar no facto de ela ter chegado, e tem de tolerar ver a mesma mensagem duas vezes sem fazer a coisa duas vezes. Nenhuma das duas é trabalho interessante, ambas são fáceis de adiar enquanto a montagem ainda está a ser testada, e juntas são a diferença entre uma ponte e um buraco.