Entrevistas de Diseño de Sistemas Frontend: De una Pregunta Vaga a un Plan Claro

Las entrevistas de diseño de sistemas frontend pueden parecer abrumadoras. Al escuchar «diseña un tablero de tareas compartido», es fácil pensar de inmediato en React, WebSockets, caché, APIs y rendimiento. El mejor inicio es más simple: define qué debe lograr el usuario antes de elegir tecnología.

Empieza por el producto, no por las librerías

Pregunta: ¿pueden los usuarios crear, editar y mover tareas? ¿El tablero es compartido? ¿Los cambios deben verse en tiempo real? ¿Los adjuntos y el trabajo sin conexión están dentro del alcance?

Después declara una suposición: diseñaré un tablero web para miembros autenticados del equipo. Podrán ver columnas, crear y mover tareas y ver cambios de sus compañeros mientras el tablero esté abierto. Los adjuntos y la edición offline quedan fuera de alcance.

Así conviertes «diseña todo Jira» en un problema concreto.

Requisitos funcionales y de calidad

Los requisitos funcionales describen comportamiento: ver el tablero, mover una tarea, filtrar y recibir cambios. La latencia, accesibilidad, fiabilidad y escalabilidad son requisitos de calidad que influyen en la arquitectura.

Cuando se mueve una tarea, el usuario arrastra la tarjeta, la interfaz se actualiza de inmediato, el cliente envía la mutación, el servidor confirma el estado canónico y otros usuarios reciben el evento. Si falla la petición, el estado se revierte.

Modelo de datos y contrato API

El cliente necesita ID de tarea, columna, posición y versión. Un contrato de actualización puede contener columnId, position y version. El servidor debe devolver la tarea canónica con una versión nueva. Si dos personas editan la misma tarea, explica una regla: last-write-wins o rechazar una versión antigua y pedir actualización.

Elige estado según propiedad y duración

Menús, vista previa de arrastre y formularios son estado local. Los filtros y el tablero elegido pertenecen a la URL. Los tableros y tareas del servidor pertenecen a una query cache. Los eventos en tiempo real actualizan o invalidan la entidad afectada, sin crear una segunda copia permanente.

Tiempo real y actualizaciones optimistas

Si basta con actualizaciones ocasionales, usa polling. Para actualizaciones unidireccionales del servidor, Server-Sent Events es razonable. Presence, escritura o colaboración bidireccional pueden justificar WebSockets. Explica primero la frescura requerida y después la tecnología.

Para una actualización optimista guarda un snapshot, actualiza la interfaz localmente, envía la mutación y restaura el snapshot si falla. Diseña el camino de error, no solo el exitoso.

Riesgos específicos del frontend

• Virtualiza listas largas.
• Haz drag-and-drop accesible con teclado y lector de pantalla.
• Diseña estados de carga, vacío, permiso denegado y reintento.
• Usa IDs estables, no índices, cuando cambia el orden.
• Mide interacciones lentas y mutaciones fallidas sin registrar contenido sensible.

Plantilla para la entrevista

1. Aclara usuarios, plataforma y flujos valiosos.
2. Declara alcance y exclusiones.
3. Enumera requisitos funcionales.
4. Conviértelos en flujos de usuario.
5. Deriva modelo de datos y contrato API.
6. Separa estado por propiedad y duración.
7. Incluye rendimiento, accesibilidad, fiabilidad y seguridad.
8. Explica trade-offs y el siguiente paso.

Conclusión

El diseño de sistemas frontend no es un concurso de librerías. Empieza por el objetivo del usuario; así las decisiones sobre estado, API, renderizado y tiempo real quedan justificadas.