Costes directos e indirectos: una definición primero
Una API de datos de mercado es una interfaz de software que proporciona información de mercado (por ejemplo, precios o cotizaciones) a una aplicación. En este contexto, los “costes” son los cargos y gastos en los que incurre para obtener, transmitir, almacenar y utilizar esa información de mercado.
Los costes se pueden agrupar en:
- Costes directos: importes facturados por el proveedor por el acceso y la entrega (por ejemplo, una tarifa de plan, cargos por solicitud o complementos para límites más altos).
- Costes indirectos: gastos que usted controla pero que cambian con su uso (por ejemplo, tiempo de cómputo, ancho de banda de red, almacenamiento en base de datos y esfuerzo de ingeniería).
Incluso cuando la lista de precios del proveedor permanece igual, su gasto total puede cambiar porque las solicitudes, el volumen de datos y los requisitos de procesamiento de su aplicación cambian.
Cómo el uso de la API de datos de mercado crea factores de coste
El acceso a los datos de mercado generalmente está impulsado por cómo consulta y consume los datos. Los factores variables clave incluyen:
- Volumen de solicitudes: número de llamadas a la API, suscripciones, símbolos o instrumentos solicitados. Más símbolos o actualizaciones más frecuentes generalmente aumentan el uso.
- Granularidad de datos y frecuencia de actualización: un mayor detalle (por ejemplo, actualizaciones más frecuentes) puede aumentar la cantidad de datos entregados.
- Método de entrega: la transmisión (streaming) frente a la consulta (polling) puede trasladar los costes entre “número de mensajes/llamadas” y “ancho de banda/rendimiento”, según la facturación del proveedor.
- Conexiones concurrentes: algunos sistemas cobran o limitan según cuántos flujos o sesiones activos mantenga.
- Necesidades de retención y reproducción: si almacena datos para análisis posteriores, sus costes de almacenamiento y recuperación aumentan con la duración de la retención y el volumen de datos.
- Requisitos de posprocesamiento: la normalización, el filtrado, la deduplicación y las transformaciones de series temporales pueden añadir tiempo de cómputo.
Supuestos para cálculos de ejemplo
Si desea estimar los costes sin depender de números en vivo, haga explícitos los supuestos:
- Solicitudes promedio por minuto (o mensajes por segundo).
- Tamaño de carga útil promedio por respuesta (o bytes promedio por mensaje).
- Período de retención en días.
- Sobrecarga de procesamiento, expresada como tiempo de cómputo por unidad de datos.
Luego puede estimar dos categorías:
- Costes relacionados con el proveedor (según su plan y las unidades de medición de uso del proveedor).
- Costes de su infraestructura (según el rendimiento, el almacenamiento y el cómputo necesarios para ingerir y utilizar los datos).
Debido a que estos supuestos están simplificados, la estimación puede ser incorrecta cuando los patrones de tráfico reales difieren.
Evidencia, verificación y una lista de verificación práctica
Dado que los proveedores y los mercados varían, la verificación consiste en alinear tres cosas: su comportamiento, el modelo de facturación del proveedor y su diseño operativo.
- Identifique las unidades de facturación del proveedor: verifique si los cargos siguen solicitudes, mensajes, suscripciones, ancho de banda, conexiones activas o campos de datos. Esto determina qué “factores variables” importan más.
- Mida su uso real: instrumente su aplicación para registrar recuentos de solicitudes, tamaños de respuesta, duraciones de suscripción y concurrencia máxima durante sesiones representativas.
- Asigne el uso a su modelo de costes: aplique sus mediciones a los términos del proveedor (por ejemplo, límites del plan y cualquier regla de exceso). Si no puede asignar directamente porque los términos no están claros, trate la estimación como incierta.
- Verifique sus costes de manejo de datos: estime el cómputo de la canalización de ingesta, el crecimiento del almacenamiento en la base de datos y los costes de copia de seguridad/retención a partir del volumen de datos medido.
- Valide el gasto en modos de fallo: verifique qué sucede durante interrupciones o reintentos. Los reintentos y el almacenamiento en búfer pueden multiplicar las solicitudes o causar procesamiento de trabajos pendientes que aumente el cómputo y el almacenamiento.
Si luego cambia la cobertura de símbolos, la frecuencia de actualización o la retención, repita la asignación. Los patrones históricos no garantizan totales futuros.
Limitaciones y riesgos materiales
Varias limitaciones pueden afectar materialmente los resultados de costes:
- Contrapresión y bucles de reintento: problemas transitorios de red o del proveedor pueden desencadenar reintentos que aumenten el volumen de solicitudes y la carga de procesamiento.
- Tráfico en ráfagas: el impacto en el coste puede estar dominado por la actividad máxima en lugar del uso promedio.
- Crecimiento del volumen de datos: una retención más larga, instrumentos adicionales o una mayor granularidad pueden aumentar el almacenamiento y el cómputo más rápido de lo esperado.
- Complejidad jurisdiccional y contractual: las obligaciones regulatorias y la redacción contractual pueden afectar lo que se le permite almacenar o redistribuir, lo que puede cambiar el coste total. Debido a que los requisitos difieren, verifique con los documentos legales y operativos del proveedor.
Además, los costes no son la única restricción: la latencia, la disponibilidad y los límites de velocidad pueden aumentar indirectamente los costes al forzar más infraestructura o diseños alternativos.
Preguntas siguientes para verificar
Para verificar de forma independiente los hechos relevantes para su situación, puede preguntar:
- ¿Qué unidad(es) de facturación utiliza el proveedor para el acceso a datos de mercado? - ¿Cómo se traduce el patrón de solicitudes/suscripciones de su aplicación en esa unidad de facturación?