Custos diretos e indiretos: uma definição primeiro
Uma API de Dados de Mercado é uma interface de software que fornece informações de mercado (por exemplo, preços ou cotações) para um aplicativo. “Custos” neste contexto são as cobranças e despesas que você incorre para obter, transmitir, armazenar e usar essas informações de mercado.
Os custos podem ser agrupados em:
- Custos diretos: valores cobrados pelo provedor pelo acesso e entrega (por exemplo, uma taxa de plano, cobranças por requisição ou complementos para limites mais altos).
- Custos indiretos: despesas que você controla, mas que mudam com seu uso (por exemplo, tempo de computação, largura de banda de rede, armazenamento em banco de dados e esforço de engenharia).
Mesmo quando a lista de preços do provedor permanece a mesma, seu gasto total pode mudar porque as requisições do seu aplicativo, o volume de dados e os requisitos de processamento mudam.
Como o uso da API de Dados de Mercado cria direcionadores de custo
O acesso a dados de mercado é tipicamente direcionado por como você consulta e consome os dados. Os principais fatores variáveis incluem:
- Volume de requisições: número de chamadas de API, assinaturas, símbolos ou instrumentos solicitados. Mais símbolos ou atualizações mais frequentes geralmente aumentam o uso.
- Granularidade dos dados e frequência de atualização: maior detalhe (por exemplo, atualizações mais frequentes) pode aumentar a quantidade de dados entregues.
- Método de entrega: streaming versus polling pode deslocar custos entre “número de mensagens/chamadas” e “largura de banda/throughput”, dependendo da cobrança do provedor.
- Conexões simultâneas: alguns sistemas cobram ou limitam com base em quantos streams ou sessões ativas você mantém.
- Necessidades de retenção e replay: se você armazena dados para análise posterior, seus custos de armazenamento e recuperação aumentam com a duração da retenção e o volume de dados.
- Requisitos de pós-processamento: normalização, filtragem, deduplicação e transformações de séries temporais podem adicionar tempo de computação.
Premissas para exemplos de cálculo
Se você quiser estimar custos sem depender de números ao vivo, torne as premissas explícitas:
- Requisições médias por minuto (ou mensagens por segundo).
- Tamanho médio do payload por resposta (ou bytes médios por mensagem).
- Período de retenção em dias.
- Overhead de processamento, expresso como tempo de computação por unidade de dados.
Então você pode estimar duas categorias:
- Custos relacionados ao provedor (do seu plano e das unidades de medição de uso do provedor).
- Custos da sua infraestrutura (de throughput, armazenamento e computação necessários para ingerir e usar os dados).
Como essas premissas são simplificadas, a estimativa pode estar errada quando os padrões de tráfego reais diferem.
Evidências, verificação e uma lista de verificação prática
Como provedores e mercados variam, a verificação trata de alinhar três coisas: seu comportamento, o modelo de cobrança do provedor e seu design operacional.
- Identifique as unidades de cobrança do provedor: verifique se as cobranças acompanham requisições, mensagens, assinaturas, largura de banda, conexões ativas ou campos de dados. Isso determina quais “fatores variáveis” importam mais.
- Meça seu uso real: instrumente seu aplicativo para registrar contagens de requisições, tamanhos de respostas, durações de assinaturas e concorrência de pico durante sessões representativas.
- Mapeie o uso para seu modelo de custo: aplique suas medições aos termos do provedor (por exemplo, limites do plano e quaisquer regras de excedente). Se você não puder mapear diretamente porque os termos não são claros, trate a estimativa como incerta.
- Verifique seus custos de manipulação de dados: estime a computação do pipeline de ingestão, o crescimento do armazenamento em banco de dados e os custos de backup/retenção a partir do volume de dados medido.
- Valide os gastos em modos de falha: verifique o que acontece durante interrupções ou repetições. Repetições e buffering podem multiplicar requisições ou causar processamento de backlog que aumenta computação e armazenamento.
Se você posteriormente mudar a cobertura de símbolos, a frequência de atualização ou a retenção, repita o mapeamento. Padrões históricos não garantem totais futuros.
Limitações e riscos materiais
Várias limitações podem afetar materialmente os resultados de custo:
- Backpressure e loops de repetição: problemas transitórios de rede ou do provedor podem acionar repetições que aumentam o volume de requisições e a carga de processamento.
- Tráfego em rajadas: o impacto no custo pode ser dominado pela atividade de pico em vez do uso médio.
- Crescimento do volume de dados: retenção mais longa, instrumentos adicionais ou maior granularidade podem aumentar o armazenamento e a computação mais rápido do que o esperado.
- Jurisdição e complexidade contratual: obrigações regulatórias e a redação contratual podem afetar o que você pode armazenar ou redistribuir, o que pode mudar o custo total. Como os requisitos diferem, verifique com os documentos legais e operacionais do provedor.
Além disso, os custos não são a única restrição: latência, disponibilidade e limites de taxa podem indiretamente aumentar os custos ao forçar mais infraestrutura ou designs alternativos.
Próximas perguntas para verificar
Para verificar independentemente os fatos relevantes para sua situação, você pode perguntar:
- Qual(is) unidade(s) de cobrança o provedor usa para acesso a dados de mercado? - Como o padrão de requisições/assinaturas do seu aplicativo se traduz nessa unidade de cobrança?