keepix.cloud — un host de medios que devuelve direcciones terminadas

01Resumen del proyecto

keepix.cloud es un anfitrión de medios para productos que tienen que servir archivos de otras personas: fotos de catálogo en una tienda, imágenes de reseñas en un mercado, video de recorrido en una aplicación. Envías el original en una solicitud firmada, y la respuesta ya lleva las direcciones terminadas: un conjunto nombrado de variantes WebP para una imagen, una escalera HLS para un video. Los archivos se sirven desde el propio subdominio del cliente, por lo que el lector ve su marca y nunca nos ve a nosotros.

La premisa es que los medios no son una característica que construyes una vez por proyecto. Cada producto que permite a las personas subir algo termina escribiendo lo mismo una y otra vez: redimensionamiento, conversión de formato, un esquema de nombres, una política de caché, eliminación de metadatos, un camino para eliminar todo sobre esta persona. Escrito una quinta vez, se escribe mal una quinta vez — y las partes que fallan (una etiqueta GPS filtrada, un SVG que resultó ser un script) fallan silenciosamente, sin un error y sin una línea de registro.

Así que construimos el servicio en torno a una idea: la dirección es declarada por el servicio y almacenada por el cliente, nunca calculada del lado del cliente. Esa única decisión elimina la forma más común en que las integraciones de medios fallan: una página que se renderiza perfectamente con un agujero donde debería estar la foto del producto.

Diseñamos y construimos todo el producto: la tubería de entrada, el modelo de variantes, la escalera de video, el modelo multi-inquilino con sus propios dominios y claves de firma, la facturación medida, el panel de control, el contrato de API pública y la documentación. A continuación se muestra qué problema resuelve, cómo está compuesto y qué decisiones de ingeniería haríamos de la misma manera nuevamente.

02Contexto y el problema

Almacenar una imagen subida es fácil. Ejecutar una ruta de medios que se mantenga correcta durante años, bajo carga, a través de varios productos y archivos de otras personas, no lo es. Cuando desglosamos la tarea, los escollos aparecieron rápidamente.

• Anchos arbitrarios son una trampa.Una URL como ?w=473 parece flexible y de hecho es dos problemas a la vez: un caché que nunca se calienta, porque cada página pide un número ligeramente diferente, y una forma gratuita para que cualquiera ocupe el procesador pidiendo mil anchos en fila.
• Una dirección calculada se rompe silenciosamente.La regla "id → shard → path", integrada en el código del cliente, sobrevive exactamente hasta el primer cambio de diseño en el otro lado. Luego, la página aún se renderiza y el producto simplemente tiene un hueco donde estaba su foto — sin error, nada en el registro.
• Los metadatos son una filtración que nadie nota.Las coordenadas GPS de la casa de alguien que están en el EXIF de una foto de reseña no generan error, no rompen ninguna página y no llegan a ningún monitoreo. Solo es una filtración cuando alguien las mira.
• SVG no es una imagen.Es un marcado ejecutable. Aceptado como una imagen y servido desde el propio dominio del cliente, un script dentro de él se ejecuta en nombre de ese dominio.
• La eliminación tiene que ser demostrable.Una solicitud de eliminación de GDPR respondida marcando filas como eliminadas mientras los bytes permanecen en el disco es una eliminación que no ocurrió.
• El video es un conjunto, no un archivo.Una carga tiene que convertirse en una escalera reproducible, un fotograma de cartel y un recurso alternativo — y nada de eso puede suceder dentro de la solicitud que aceptó el archivo.
• La facturación tiene que ser honesta con números pequeños.Un gigabyte puede costar menos de un centavo; redondear a centavos enteros consume toda la factura medida y convierte la factura en una ficción.

Había un requisito más, y dio forma a todo el diseño: el servicio no debe salir a internet en absoluto. Un host de medios que obtiene una imagen de una dirección de terceros en nombre del cliente sabe quién pidió qué y entrega ese conocimiento a cualquier CDN que utilizó. keepix no conoce ninguna dirección de terceros, y esa es una propiedad del código, no una promesa en la página de precios.

03Objetivos del proyecto

La tarea se convirtió en una lista de objetivos que manteníamos en cada etapa:

• Una solicitud entrante, direcciones salientes terminadas. El cliente envía el original y recibe inmediatamente las direcciones para almacenar — sin segunda llamada, sin esperar a que un trabajo termine para las imágenes.
• Un conjunto nombrado y finito de variantes. Tres anchos para imágenes y cuatro formas para video, declarados por tipo de archivo, para que la caché esté caliente y el procesador no esté en alquiler.
• El dominio propio del cliente. Archivos servidos desde img.sudominio, con el servicio invisible en la barra de direcciones.
• Una caché que se puede mantener para siempre. La dirección lleva un hash del contenido, por lo que reemplazar un archivo cambia su dirección y llega al lector de inmediato.
• Seguridad incorporada en la ruta. Tipo determinado por análisis, un escaneo de virus que rechaza en lugar de dejar pasar, re-codificación en cada imagen, metadatos eliminados, SVG rechazado en ambos extremos.
• Borrado comprobable. Una solicitud por el propio owner_ref, y una respuesta que nombra cuántos objetos y archivos fueron.
• Multi-inquilino con aislamiento real.Propios dominios, propios tipos y variantes, propios límites, dos claves de firma para que la rotación no sea un tiempo de inactividad.
• Facturación medida que puedes verificar.Almacenamiento como un promedio en lugar de un pico, tráfico como los bytes realmente entregados, operaciones contadas una por una — desglosadas por día en el panel.
• Una API que admite lo que hizo.Cada respuesta dice lo que se hizo y lo que se omitió, y hay un punto final de reconciliación seca para verificar una migración en lotes.

04Lo que hicimos

keepix se divide en unas pocas piezas claras, cada una con un trabajo:

• Recepción. Un endpoint firmado acepta el original con su tipo, su clave y la lista de variantes deseadas. Las imágenes regresan listas en la misma respuesta; el video entra en una cola y la respuesta lo indica.
• La tubería de procesamiento. Detección de tipo, escaneo de virus, re-codificación, eliminación de metadatos, construcción de variantes — en un orden fijo que no se puede omitir por solicitud.
• Entrega. Un host separado sin sesiones, sin JavaScript y sin Set-Cookie, sirviendo archivos directamente desde el disco con una caché inmutable de un año.
• La API del inquilino. Firmada con HMAC-SHA256, con endpoints para resolver direcciones, reconciliar en lotes, exportar un inventario, eliminar un objeto y borrar todo lo que pertenece a una persona.
• El panel de control. Carpetas, arrastrar y soltar, búsqueda por título, descripción y etiquetas — y uso desglosado por día. Funciona completamente sin JavaScript; el script añade comodidad, no la capacidad de trabajar.
• Facturación. Paquetes más sobrecarga medida, mantenida en centésimas de centavo, con la entrada deteniéndose en lugar de gastar dinero en silencio en el plan gratuito.
• El stock. Una capa de mercado donde los inquilinos pueden comprar y vender su propio trabajo, compartiendo el mismo almacenamiento y ruta de entrega.

Todo lo siguiente es una mirada más cercana a las decisiones dentro de esas piezas — las que serían costosas de cambiar más tarde.

05Arquitectura de la solución

El servicio es tres espacios con puntos de entrada físicamente separados, y esa separación es la columna vertebral de todo el diseño:

• Entrega pública — sin API en absoluto. El servidor web busca el archivo en el disco y lo sirve. No encontrado significa 404, no "generarlo sobre la marcha". No hay código ejecutable en ese camino, por eso el host de entrega puede llevar default-src 'none'; sandbox y lo dice en serio.
• La API privada del inquilino. Cada solicitud firmada; la firma cubre el método, el camino con su cadena de consulta, la marca de tiempo y un hash del cuerpo. Firmar el camino sin la consulta dejaría tipo y clave sin firmar — intercambiable, y nadie lo notaría.
• La API de administración para el panel de control, en su propio punto de entrada con sus propias credenciales.

Las respuestas son siempre JSON y siempre en inglés, con una redacción por código de rechazo — así que el mismo fallo se lee igual en el registro de cada cliente, sea cual sea el idioma que hable su producto.

Dentro, el almacenamiento se divide en un árbol frío que contiene originales, que nunca se sirve hacia afuera, y el árbol servido de variantes. Mantener el original es lo que hace posible una nueva variante un año después sin pedir al cliente que suba nada de nuevo — y también es por eso que "no servimos el archivo que enviaste" puede ser una regla absoluta en lugar de una habitual.

06La vida de un archivo

Un archivo pasa por una secuencia fija, y el orden es el punto:

• El tipo se determina mediante el análisis — del contenido, no de la extensión y no de lo que el cliente dice que es. La extensión del archivo de salida es asignada por el servicio.
• El escaneo de virus se ejecuta, y puede rechazar. Si el escáner no es accesible, la entrada responde 503 en lugar de dejar pasar el archivo. Pasar un archivo en silencio mientras la verificación está caída es una mentira sobre el trabajo realizado, y es el tipo de mentira que solo sale a la luz mucho después.
• La imagen se vuelve a codificar. No se sirve de vuelta ni un byte del archivo que llegó.
• Los metadatos no sobreviven a la recodificación. EXIF y GPS se pierden debido a cómo se construye la ruta, no porque quien lo subió recordara eliminarlos.
• Las variantes se construyen y sus direcciones se devuelven en la misma respuesta.

SVG no es aceptado ni servido — nunca, ni al entrar ni al salir. La verificación se realiza dos veces, en el tipo de contenido declarado y en los primeros bytes del archivo, porque para SVG un detector de tipo a menudo solo dirá "texto". Lo que se sirve es WebP, JPEG, PNG, MP4, una lista de reproducción HLS y sus segmentos; todo lo demás es un 415.

La entrada es idempotente: el mismo sha256 bajo la misma clave no vuelve a hacer el trabajo y devuelve las mismas direcciones. Los reintentos después de una conexión rota son, por lo tanto, gratuitos, lo que importa cuando el archivo tiene dos gigabytes y la red es un teléfono.

07Variantes nombradas, no anchos arbitrarios

Las imágenes tienen tres anchos nombrados — miniatura 400, tarjeta 1000, completo 1400, todos WebP con calidad 82 — y pides una variante por nombre. El conjunto es finito y declarado por tipo de archivo. Esta es la decisión en la que se basa todo el servicio, y elimina una clase de problemas en lugar de un error.

Dos reglas rigen cuándo una variante puede no aparecer legítimamente, y ambas existen para evitar mentir al lector:

• Nada se estira. Si el original es más estrecho que el ancho de la variante, la variante se mantiene al tamaño del original y la respuesta lo dice honestamente — los w y h campos llevan los números reales. Una copia ampliada parece un error del servicio, y lo sería.
• Las copias idénticas no se almacenan dos veces.Si dos anchos producirían el mismo archivo, no se crea la segunda dirección. Dos archivos idénticos en bytes en dos direcciones son dos descargas de la misma cosa en el teléfono de alguien.

Lo que significa que la respuesta debe ser leída, no asumida: puedes pedir dos variantes y obtener una, con un omitido bloque que explica por qué. Hicimos de eso una respuesta normal y esperada en lugar de un caso extremo, porque una integración escrita contra la forma optimista falla con la primera imagen pequeña que un usuario sube.

Agregar una nueva variante más tarde no requiere volver a subir nada: se construye a partir del original en el árbol frío. Esa es la razón principal por la que se mantiene el original.

08Video: una escalera HLS, un cartel y una vista previa

Una carga de video se convierte en un conjunto, porque eso es lo que realmente necesita un reproductor: un escalera HLS de hasta tres pasos de calidad (640, 1280 y 1920 px), un poster tomado al 10% de la duración, un preview clip silencioso de los primeros segundos para la reproducción automática al pasar el mouse y en el feed, y un MP4 como respaldo para clientes más antiguos.

No se hace un paso más ancho que el original, por la misma razón que no se hace una imagen estirada: una copia ampliada parece un error del servicio. El poster se toma en una décima de la duración en lugar de en el primer fotograma, porque el primer fotograma de un video real es muy a menudo negro.

El procesamiento de video no ocurre dentro de la solicitud que aceptó el archivo; va a una cola, y la respuesta lo indica. La respuesta de recepción es honesta sobre qué partes están listas ahora y cuáles están pendientes, para que un cliente pueda almacenar lo que tiene y preguntar de nuevo más tarde en lugar de bloquear la pantalla de carga de un usuario en una transcodificación.

09Tu propio dominio y un caché para siempre

Los archivos se sirven desde el subdominio propio del inquilino — img.sudominio — al que el inquilino apunta al servicio con un registro A. El lector ve su marca y su dirección, y no ve keepix en absoluto. En el plan gratuito, el dominio es compartido; ambos caminos funcionan de la misma manera.

Un inquilino puede conectar tantos dominios como desee, pero exactamente uno canónico uno, y esa restricción es deliberada: con dos dominios canónicos, un archivo obtiene dos direcciones, lo que significa dos cachés y los mismos bytes descargados dos veces en el teléfono del mismo lector.

Los encabezados de entrega son los mismos para cada inquilino y no cambian: un año completo inmutable caché, nosniff, default-src 'none'; sandbox, una política CORS permisiva para lectura, y no un solo Set-Cookie. El caché eterno es seguro precisamente porque la dirección lleva un hash del contenido: cambia los bytes y la dirección cambia con ellos, así que una imagen reemplazada llega al lector inmediatamente en lugar de esperar un TTL.

Y esa es exactamente la razón por la que la dirección no puede ser calculada del lado del cliente. Es devuelta por el servicio, almacenada junto al registro al que pertenece, y solicitada de nuevo a través de resolver si alguna vez se pierde.

10Ingreso: tipo, escaneo de virus, metadatos

Todo en el servicio es un archivo que alguien envió: una foto en una reseña, un video de recorrido. Las reglas de ingreso están escritas para su beneficio en lugar de por formalidad, y cada uno de ellos existe porque la alternativa falla silenciosamente.

Determinar el tipo mediante análisis en lugar de por extensión no es pedantería: la extensión es lo único que un cargador controla completamente.Rechazar cuando el escáner está inactivo cuesta disponibilidad y compra la garantía de que "escaneado" significa escaneado.Re-codificar cada imagen significa que un archivo elaborado nunca llega a un lector en su forma original.Eliminando metadatos durante esa re-codificación significa que no puede ser olvidado.

En el lado de la entrega, las garantías son estructurales en lugar de procedimentales. El host de entrega no tiene sesiones, no tiene JavaScript y no tiene código ejecutable en el camino; el contenido se envía con una política de seguridad de contenido que impediría que un navegador ejecutara cualquier cosa, incluso si algo peligroso hubiera entrado. Dos capas independientes, porque los fallos interesantes son aquellos donde la primera capa estaba mal configurada y nadie se dio cuenta.

El registro de entrega, con las direcciones de los lectores en él, vive 24 horas. Nada en el servicio lo necesita por más tiempo, lo que hace que mantenerlo más tiempo sea simplemente una acumulación de las huellas de otras personas.

11Borrando todo sobre una persona

Cada objeto lleva un owner_ref — como el inquilino llama al propietario de ese archivo. Para las imágenes de catálogo está vacío: no se trata de una persona. Para las fotos de reseñas y videos de usuarios es obligatorio.

Una solicitud borra todo lo que está debajo de ella, y la respuesta nombra un número: cuántos objetos y cuántos archivos se fueron. Ese número es el punto del endpoint. Una puerta de datos personales debería verificar la ejecución, no la intención — una fila marcada como eliminada mientras los bytes aún están en el disco es una eliminación que no ocurrió, y seguirá sin ocurrir hasta que alguien lo mire.

La eliminación elimina registros y bytes a la vez en lugar de según un horario, y lleva consigo las copias diferidas de versiones anteriores. También es la parte que hace que keepix sea utilizable desde un producto con sus propias obligaciones de GDPR: un flujo de eliminación en el código del cliente puede llamarlo en línea y leer el conteo de vuelta, en lugar de confiar en que un trabajo de limpieza en algún lugar lo abordará.

Las claves de firma funcionan de la misma manera.Un inquilino siempre tiene dos en uso, porque con una rotación de clave significa tiempo de inactividad — y el tiempo de inactividad es la razón por la que la rotación se pospone para siempre. El secreto se muestra una vez al emitirse y nunca se devuelve al panel de control: poder firmar una solicitud es el derecho a escribir en el almacenamiento de otra persona.

12Una API firmada y reconciliación

Cada solicitud privada lleva cuatro encabezados — inquilino, id de clave, marca de tiempo y firma — y la firma es HMAC-SHA256 sobre el método, la ruta completa con consulta, la marca de tiempo y el hash del cuerpo. La ventana es de 300 segundos. Una solicitud firmada idéntica repetida dentro del mismo segundo es rechazada como una repetición, que es la protección funcionando como se pretende, y el contrato lo dice claramente en lugar de dejar que los integradores lo descubran.

El conjunto de puntos finales es pequeño y cada uno responde a una pregunta operativa real:

• poner — aceptar un original; poner-variante — aceptar una copia ya terminada sin volver a codificarla, para mover lo que un cliente ya tiene. Volver a codificar una copia terminada significa perder calidad sin razón.
• resolver y resolver-lote (hasta 1000 claves) — qué direcciones tiene esta clave. Esta es una herramienta de reparación: si se pierde un registro, preguntas en lugar de adivinar.
• reconciliar — una verificación en seco, hasta 1000 registros a la vez, que no cambia nada y responde ok / falta / desajuste / pendiente por registro más un resumen del lote.
• inventario — la exportación que realiza la comparación en la otra dirección, la lista del servicio contra la del cliente, paginada por la clave misma para que la página no se desplace mientras se aceptan cosas en medio del proceso.
• objeto, borrar, cuota, ping, y un sin firmar healthz que dice que el front end está vivo y nada más — sin versión, sin estado de base de datos.

La reconciliación merece su propia nota, porque es el punto final que justifica todo el contrato. Después de una gran migración, hay exactamente una pregunta que importa: ¿todo pasó? Responderla un archivo a la vez significa tantas solicitudes como archivos hay, así que nadie lo hace — y luego se declara que una migración ha terminado basándose en que el script de carga no se ha bloqueado. La reconciliación por lotes hace que la respuesta honesta sea lo suficientemente barata como para obtenerla realmente.

13Tablero, uso y facturación

El panel es una biblioteca sin código en absoluto: carpetas, arrastrar archivos con el ratón, búsqueda por título, descripción y etiquetas. Funciona completamente sin JavaScript — el script añade conveniencia, no la capacidad de trabajar. Eso no es nostalgia; es la forma más barata de garantizar que el panel siga siendo utilizable en una mala conexión y siga siendo comprobable sin un motor de navegador.

El uso se cuenta desde el inicio del mes y se desglosa por día: cuánto almacenamiento, cuánto tráfico de entrega y cuántas operaciones cayeron en cada fecha, cuánto del paquete se consume y qué vino encima. El desglose importa más que el total — una factura que no puedes atribuir a un día es una factura con la que no puedes discutir.

Tres decisiones en la facturación merecen ser mencionadas:

• El almacenamiento es el promedio durante el período, no el pico.Un solo día con una gran carga no debería costar todo el mes.
• El tráfico de entrega son los bytes realmente entregados, tomados del registro del servidor — no "tamaño del archivo × número de solicitudes", lo que exagera cada solicitud de rango y cada descarga abandonada.
• Las tarifas se mantienen en centésimas de centavo.Un gigabyte puede costar menos de un centavo; redondear a centavos enteros consumiría toda la factura medida y convertiría silenciosamente la factura en ficción.

En el plan gratuito no hay facturación medida en absoluto: la ingesta se detiene en lugar de comenzar a gastar el dinero del cliente en silencio. Un servicio que decide por sí mismo facturar a alguien que nunca ingresó una tarjeta es un servicio que nadie recomienda dos veces.

14Pila tecnológica

Elegimos la pila para un servicio cuyo camino caliente es un servidor web que entrega un archivo:

• PHP 8.4 para la API y el panel de control — maduro, lo suficientemente rápido en este camino y barato de mantener, lo cual es importante para un producto con un nivel gratuito.
• Un host de entrega dedicado sirviendo directamente desde el disco, sin código de aplicación en el camino de la solicitud en absoluto.
• WebP para imágenes de calidad fija, H.264 + AAC en HLS para video con un retroceso progresivo en MP4.
• Una cola para trabajos de video, por lo que una transcodificación nunca se encuentra dentro de una solicitud de carga.
• HMAC-SHA256 firma de solicitud con dos claves en vivo por inquilino y una ventana de 300 segundos.
• Un árbol frío de originales fuera de la ruta servida, que es lo que hace posibles nuevas variantes y reconstrucciones más tarde.

El servicio es deliberadamente conservador en lo que depende. No realiza solicitudes salientes por su cuenta, no utiliza CDN de terceros y no mantiene registros sobre los usuarios del cliente más allá de inquilino, clave, tipo, conteo de bytes y variantes. Cada dependencia que no tienes es una dependencia que no puede romper tu medio un martes.

15Diseño y UX

El sitio público tenía un trabajo: hacer que un producto de infraestructura sea legible para el ingeniero que realmente lo integrará. Así que la primera pantalla muestra la solicitud real y la respuesta real — las direcciones que regresan en JSON — en lugar de una abstracción de ellas. Un integrador decide en unos treinta segundos si un servicio de medios se ajusta a su código, y decide al mirar la forma de su respuesta.

El resto del sitio está escrito de la misma manera. Cada capacidad se declara junto con su restricción: variantes nombradas ypor qué se rechazan los anchos arbitrarios; una caché eternayel hash en la dirección que lo hace seguro; un punto final de borradoyel número con el que responde. La documentación que solo enumera lo que un servicio puede hacer deja al lector descubrir los límites en producción.

En el panel, el mismo principio se convierte en la línea base sin JavaScript y el desglose de uso día a día: nada en pantalla que el lector no pueda verificar, y nada que deje de funcionar cuando un script no se carga.

16Cómo trabajamos

El proyecto se llevó a cabo en etapas, cada una terminando en algo demostrable:

• Contrato primero.Escribimos el contrato de la API — esquema de firma, puntos finales, códigos de rechazo, formas de respuesta — antes de la implementación, porque el contrato es la parte contra la que los clientes construyen y la parte que es costosa de cambiar.
• Recepción y variantes.El pipeline, en su orden fijo, con las dos reglas sobre no estirar y no almacenar duplicados incorporadas desde el principio.
• Entrega.El host separado, el conjunto de encabezados, la dirección con hash de contenido que hace que la caché eterna sea segura.
• Video.La escalera, el cartel y la vista previa, y la cola que sigue transcodificando fuera de la solicitud de carga.
• Multi-inquilino.Dominios, tipos, variantes, límites y el modelo de rotación de dos claves.
• Facturación y panel de control.Contador medido con un desglose día a día, luego la interfaz de usuario de la biblioteca encima de eso.
• Una migración real.Movimos un catálogo en vivo al servicio y lo reconciliamos en lotes, que es cómo el punto final de reconciliación adquirió su forma.

Esa última etapa valió más que cualquier cantidad de pruebas internas. Mover cientos de miles de archivos reales encontró cosas que un conjunto de pruebas no hace: objetos que el servicio aceptó y perdió, registros cuya dirección almacenada se había desviado, y la diferencia entre una verificación que verifica hashes y una verificación que simplemente confirma que una fila existe. Una verificación sin nada más que verificar informa éxito, así que hicimos que el modo débil dijera en qué modo se encuentra.

17El resultado

Lo que salió es un host de medios en el que un producto puede apoyarse: una solicitud firmada entra, direcciones terminadas salen, servidas desde el dominio del cliente con una caché que se puede mantener para siempre.

• Variantes nombradas y una escalera HLS, construidas una vez y almacenadas en caché para siempre detrás de una dirección con hash de contenido.
• El subdominio propio del cliente: el lector ve su marca, no la nuestra.
• Seguridad incorporada en el camino de entrada: tipo analizado, rechazo de escaneo de virus, re-codificación, metadatos eliminados, SVG rechazado en ambos extremos.
• Borrado que responde con un número, para que una puerta de datos personales pueda verificar la ejecución en lugar de la intención.
• Multi-inquilino con dominios propios, techos propios y rotación de dos claves sin tiempo de inactividad.
• Facturación medida mantenida en centésimas de centavo, desglosada por día, y un plan gratuito que se detiene en lugar de gastar.

18Conclusiones

keepix es un caso donde la mayor parte de la ingeniería se dedicó a decidir qué haría el servicio rechazar hacer. Sin anchos arbitrarios, sin direcciones calculadas, sin SVG, sin solicitudes salientes, sin mantener los bytes originales en la ruta servida, sin facturación en el plan gratuito. Cada uno de esos elimina toda una clase de fallos en lugar de manejar uno.

La lección principal que llevaríamos al próximo proyecto de infraestructura: hacer que la respuesta honesta sea barata de obtener. Reconciliación por lotes, uso desglosado por día, un borrado que devuelve un conteo, una respuesta de ingreso que nombra lo que se omitió — en cada caso, la alternativa no era una respuesta incorrecta, sino ninguna respuesta en absoluto, y ninguna respuesta es lo que los equipos aceptan en silencio.

Si necesitas un servicio de medios bajo tu propio dominio, un canal de archivos que debe ser seguro con las cargas de otras personas, o un producto API-first donde el contrato importa más que las pantallas, este es el tipo de trabajo que hacemos de principio a fin.