M.Video restablece su web y su app tras una avería en un proveedor de nube

La cadena M.Video ha restablecido el funcionamiento de su web y de su aplicación móvil tras un fallo técnico que comenzó el 11 de octubre de 2026. Según su servicio de prensa, la causa fue una avería en un proveedor de nube. Parte de los servicios responde por ahora más despacio de lo habitual.

La compañía no ha nombrado al proveedor, no ha precisado cuántas horas duró la caída y no ha indicado cuántos pedidos se vieron afectados. Por ahora, el relato se apoya en un único comunicado oficial. Todo lo que vaya más allá sigue siendo una suposición.

Qué se sabe del fallo

Las interrupciones comenzaron el domingo 11 de octubre. La empresa anunció la recuperación el 12 de octubre. Según su versión, los problemas pudieron afectar a la tramitación de compras, a la entrega y a la consulta de información sobre pedidos. La fórmula es cautelosa: «pudieron afectar» no equivale a «afectaron a todos». Se desconoce cuántos clientes no lograron completar un pedido o no pudieron ver su estado.

Los datos clave por ahora:

• Inicio del fallo: 11 de octubre de 2026
• Anuncio de la recuperación: 12 de octubre de 2026
• Causa: avería en un proveedor de nube, cuyo nombre no se ha revelado
• Afectados: sitio web y aplicación móvil
• Posible impacto: tramitación de compras, entrega, información sobre pedidos
• Estado actual: servicio restablecido, parte de los servicios más lenta

Por qué una avería en el proveedor golpea al comercio minorista

Para una cadena de electrónica, la web y la aplicación llevan tiempo siendo el principal canal de ventas. Detrás del escaparate hay un carrito, el pago, el almacén, la logística y el área personal del cliente. Si todos estos componentes viven en una misma nube, una sola avería del proveedor detiene toda la cadena, desde la elección del producto hasta la llamada del mensajero.

La lentitud posterior a la recuperación también es habitual. La compañía no ha explicado sus causas, pero en estos casos suele intervenir uno de tres mecanismos. Las solicitudes acumuladas generan un pico de carga. Hay que volver a calentar las cachés. Los datos entre sistemas se sincronizan con retraso. Por eso, «el servicio ha vuelto» y «el servicio funciona como antes» siguen siendo estados distintos.

La pregunta principal de esta historia no tiene que ver con M.Video, sino con la arquitectura. ¿Tenía la empresa un esquema en el que la tramitación de pedidos siguiera funcionando, aunque fuera en modo simplificado, cuando la nube no está disponible? El comunicado no deja ver la respuesta.

Qué hacer, para compradores y empresas

Quienes hicieron un pedido el 11–12 de octubre deberían comprobar su estado en el área personal o con el operador. No hace falta volver a pagar el pedido sin asegurarse antes de que el primer pago no se procesó: con sistemas inestables pueden producirse duplicados. Conviene guardar los justificantes de pago y las capturas de pantalla.

Para las empresas cuyas ventas dependen de la nube, el episodio deja una breve lista de comprobación:

• Elaborar un mapa de dependencias y entender qué servicios están alojados en un mismo proveedor.
• Identificar el circuito crítico (carrito, pago, estados de pedidos) y garantizarle una réplica en otra zona o en otro proveedor.
• Definir de antemano el modo degradado: qué se desactiva y qué sigue disponible.
• Mantener una página pública de estado y plantillas de comunicación listas para los clientes.
• Hacer simulacros de caída del proveedor, y no solo de caída de un servidor.

Mientras M.Video no revele los detalles, es imposible evaluar la magnitud de las pérdidas y las lecciones del episodio. Si la compañía nombra al proveedor y la duración de la caída, se podrá saber si el fallo fue puntual o si refleja un punto débil en su esquema de alojamiento.