En SwimUpvote, el problema de ingeniería es coordinar tareas sobre perfiles de Reddit y mantener su estado visible para el operador. El panel conecta campañas, perfiles, trabajos programados y resultados de ejecución. Aquí explico esa arquitectura y lo que permiten revisar sus capturas.
Las imágenes están sanitizadas. Muestran la estructura del producto, pero no son una prueba de rendimiento, de volumen sostenido ni de resultados comerciales. No publico una cifra de cuentas operadas o tareas completadas porque este caso no aporta una medición que la respalde.
El problema: coordinar perfiles, tareas y entornos
Una tarea necesita un perfil, un entorno disponible y un momento de ejecución. Si esa información está repartida entre hojas de cálculo y scripts, investigar un fallo obliga a reconstruir el recorrido a mano. SwimUpvote centraliza el inventario de perfiles, sus estados, las campañas y la cola de trabajo.
La pregunta operativa es concreta: ¿qué se pidió, qué recurso se asignó y qué resultado volvió? Esa relación permite revisar el trabajo pendiente y localizar la ejecución que necesita atención.
Separar el panel, la cola y los workers
La base técnica descrita en el proyecto reparte las responsabilidades:
- El backend y el panel gestionan perfiles, campañas, tareas y registros.
- RabbitMQ separa la creación del trabajo de su ejecución.
- Los consumidores de AdsPower ejecutan los flujos de navegador.
- El planificador de GeeLark coordina entornos móviles con Appium y ADB.
- Los bloqueos por cuenta o perfil evitan ejecuciones simultáneas incompatibles.
- Los estados START, HEARTBEAT, END y ERROR y los logs devuelven información al backend.
- Los reintentos con espera progresiva atienden fallos recuperables.
Separar estas piezas facilita localizar un problema de planificación, de ejecución o de registro. Para las decisiones del broker, la guía de arquitectura con RabbitMQ desarrolla confirmaciones, reentregas y límites. Son criterios de diseño generales, no una certificación de todas esas garantías en este caso.
Dos tipos de ejecución: navegador y móvil
SwimUpvote coordina perfiles de navegador mediante AdsPower y entornos móviles mediante GeeLark, Appium y ADB. En el flujo móvil, el planificador reserva un slot, prepara el dispositivo, abre la sesión de automatización y devuelve el resultado al backend. La cuenta queda bloqueada mientras tiene un trabajo activo.
El panel mantiene una vista común, aunque la ejecución sea distinta. El coste técnico de esa decisión es mantener dos caminos de diagnóstico: un error de sesión del navegador y un fallo del dispositivo necesitan información diferente. La guía de colas para bots móviles explica cómo plantear propiedad del dispositivo, recuperación y revisión del resultado.
Qué evidencia puede revisar el operador
La cola de tareas reúne tipo de trabajo, perfil, campaña, estado, programación y referencia a captura. Junto con los logs, sitúa el fallo dentro de una ejecución concreta. La captura siguiente muestra esa organización; el contenido de las filas está difuminado.
Un estado final y una captura ayudan a investigar, pero no demuestran por sí solos que se haya cumplido el objetivo de negocio. En un nuevo encargo acordaría qué resultado debe comprobarse y qué casos necesitan revisión humana. El caso Adslyfy muestra otra aplicación de evidencia operativa, centrada en monitorización de anuncios.
Campañas y búsqueda dentro del panel
La vista de descubrimiento permite revisar conversaciones y relacionarlas con campañas o tareas. Su papel en este caso es mostrar cómo el panel conecta la selección de trabajo con su seguimiento. No atribuyo a esa interfaz mejoras de conversión, alcance o captación.
La capacidad necesita medirse
Un inventario grande, la concurrencia y el trabajo completado son magnitudes distintas. Añadir workers o slots no garantiza que el sistema procese más tareas: pueden limitarlo la duración de cada flujo, la disponibilidad de entornos o las dependencias externas.
Antes de comprometer capacidad en otro proyecto, definiría una mezcla representativa de tareas y mediría tiempo de espera, duración, errores, reintentos y revisión manual. También comprobaría qué ocurre al perder un worker o un entorno. Son pruebas propuestas para una contratación, no resultados ya obtenidos por SwimUpvote.
Qué acordar antes de construir una plataforma similar
Si tu equipo coordina trabajo entre varios sistemas y pierde el rastro al fallar una tarea, puedo revisar el proceso dentro del servicio de automatización empresarial. Cuando el problema principal es reunir estados y datos de sistemas existentes, el punto de partida es plataformas internas e integraciones.
Para delimitar el encargo, propongo concretar estos puntos con el equipo que va a operar el sistema:
| Decisión | Qué dejar por escrito |
|---|---|
| Trabajo incluido | Flujos, entradas, resultado esperado y tareas que seguirán siendo manuales. |
| Recursos y dependencias | Entornos disponibles, sistemas conectados y restricciones de concurrencia. |
| Fallos y recuperación | Cuándo reintentar, cuándo parar y quién revisa un resultado incierto. |
| Evidencia de entrega | Una muestra de tareas que pueda seguirse desde la petición hasta el resultado, incluidos fallos. |
| Operación posterior | Accesos, documentación, mantenimiento y cobertura de incidencias que se acuerde. |
Con ese alcance se pueden comparar presupuestos de automatización sin confundir una interfaz con toda la operación que necesita detrás. La tabla es una propuesta de alcance; no enumera nuevas funciones de SwimUpvote.
Revisemos dónde se pierde el control
Este caso documenta panel, colas, workers, bloqueos y registros. Mantengo fuera los payloads, credenciales, identidades, selectores y configuraciones internas. La evidencia útil es cómo se relacionan las piezas y qué necesita ver el operador.
Si estás valorando una plataforma de automatización, cuéntame el proceso que quieres coordinar, los sistemas implicados y un ejemplo de fallo sin datos sensibles. Podemos convertirlo en un primer alcance y en criterios concretos para aceptar la entrega.