Estoy creando una aplicación web con Ruby on Rails que necesita ser altamente escalable. En esta aplicación, los datos son producidos por un cliente móvil (aproximadamente 20 bytes) cada segundo. Todos estos datos deben transferirse a un servidor en algún momento, preferiblemente lo antes posible.

Para realizar esta tarea, quiero que el servidor actúe como un servicio RESTful. El cliente podría almacenar ubicaciones en el búfer (por ejemplo, cada 5 a 30 segundos) y luego dispararlas como una solicitud de colocación HTTP, donde el servidor podría almacenarlas. Creo que este modelo es más sencillo de implementar y maneja mejor el tráfico de alto volumen, ya que los clientes pueden seguir almacenando datos en el búfer hasta que escuchen una respuesta del servidor.

Mi jefe, por otro lado, quiere implementar el servidor usando la programación de socket. Él cree que la programación del socket dará como resultado que se transfieran menos datos, lo que aumentará la eficiencia total del sistema. No puedo estar en desacuerdo sobre este punto, pero creo que, dado el ancho de banda moderno, la sobrecarga adicional con HTTP vale la pena. Además, creo que tratar de mantener miles (o millones) de conexiones simultáneas con los usuarios causará sus propios problemas y aumentará en gran medida la complejidad del servidor.

Sinceramente, no conozco el enfoque correcto para este problema, así que pensé en publicarlo aquí y obtener las opiniones de personas mucho más inteligentes que yo. Agradecería que las respuestas incluyeran los pros y los contras de la solución propuesta.

Gracias

Actualiza

Ahora tenemos algunos requisitos adicionales eliminados. Primero, el cliente móvil no puede cargar más de 5 GB de datos por mes. En este caso, estamos hablando de un mensaje por segundo durante ocho horas al día por mes. En segundo lugar, queremos combinar los mensajes lo menos posible. Esto es para garantizar que si algo le sucede al cliente móvil (por ejemplo, un accidente automovilístico), perdemos la menor cantidad de datos posible.