System Design en Entrevistas 2026: Guía para Empezar

Te sientas frente al entrevistador, te suelta “diseña un sistema tipo WhatsApp” y de repente se te borra todo: bases de datos, colas, cachés, escalado, latencia, todo mezclado. Si estás preparando entrevistas para backend, full stack, data, platform o staff engineer en 2026, System Design ya no es “un extra bonito”, es una parte donde muchas candidaturas buenas se caen.

System Design en entrevistas 2026: por qué importa tanto#

System Design es la entrevista donde no te piden escribir un algoritmo perfecto en 35 minutos. Te piden pensar como alguien que puede construir sistemas reales, con usuarios reales, fallos reales y costes reales.

Empresas como BBVA, Telefónica, Cabify, Glovo o Inditex no solo quieren saber si sabes programar. Quieren ver si entiendes qué pasa cuando tu código recibe millones de peticiones, cuando una base de datos se satura, cuando un servicio externo falla o cuando el producto crece más rápido de lo previsto.

En 2026, esta entrevista aparece cada vez más en procesos para:

• Backend Engineer.
• Full Stack Engineer senior.
• Software Engineer II o III.
• Platform Engineer.
• DevOps o SRE.
• Data Engineer.
• Engineering Manager técnico.
• Staff Engineer.

Si vas a posiciones junior, puede salir en versión sencilla. Si vas a senior, se espera que lideres la conversación. Y si apuntas a rangos de €45k, €60k, €70k o más en España o remoto Europa, System Design puede decidir si avanzas o no.

La buena noticia: no necesitas memorizar cien arquitecturas. Necesitas una forma clara de pensar.

Qué evalúan realmente en una entrevista de System Design#

Mucha gente cree que la entrevista consiste en adivinar la arquitectura “correcta”. No va de eso.

El entrevistador quiere ver cómo razonas cuando hay ambigüedad. Quiere comprobar si puedes hacer preguntas, tomar decisiones, explicar trade-offs y ajustar tu diseño según los requisitos.

Normalmente evalúan esto:

1. Claridad para entender el problema
   Antes de diseñar, debes preguntar. ¿Cuántos usuarios? ¿Qué funciones son clave? ¿Qué latencia se espera? ¿Hay pagos? ¿Hay datos sensibles?

2. Capacidad para dividir el sistema
   Un sistema grande se rompe en piezas: API, servicios, base de datos, caché, cola, almacenamiento, autenticación, monitorización.

3. Conocimiento de escalabilidad
   No hace falta sonar como arquitecto de Netflix, pero sí entender lectura vs escritura, particionado, balanceadores, caché y replicación.

4. Buen juicio técnico
   Elegir PostgreSQL cuando basta PostgreSQL es mejor que meter Kafka, Cassandra, Redis, Kubernetes y cinco microservicios sin motivo.

5. Comunicación
   En muchas entrevistas, la forma de explicar vale casi tanto como el diseño. Si el entrevistador no entiende tu razonamiento, tu arquitectura pierde fuerza.

Piensa en esta entrevista como una conversación técnica, no como un examen oral.

El marco mental que te salva: 7 pasos#

Si no sabes por dónde empezar, usa siempre el mismo marco. Esto te da estructura y reduce el bloqueo.

1. Aclara requisitos funcionales

Empieza con preguntas simples:

• ¿Qué debe hacer el sistema?
• ¿Qué funcionalidades son obligatorias?
• ¿Qué queda fuera de esta versión?
• ¿Usuarios autenticados o anónimos?
• ¿Hay roles, permisos o pagos?

Si te piden “diseña Instagram”, no intentes diseñar todo Instagram. Acota.

Podrías decir:

“Para no irme demasiado lejos, voy a centrarme en subir fotos, seguir usuarios, ver feed y dar likes. Dejo fuera mensajes, reels y anuncios, salvo que quieras que los incluyamos.”

Eso suena maduro. No suena limitado.

2. Aclara requisitos no funcionales

Aquí entran escala, rendimiento, disponibilidad y consistencia.

Pregunta cosas como:

• ¿Cuántos usuarios diarios esperamos?
• ¿Cuántas lecturas y escrituras por segundo?
• ¿Qué latencia máxima aceptamos?
• ¿El sistema debe seguir funcionando si una región cae?
• ¿Necesitamos consistencia fuerte o eventual?

Ejemplo: en un sistema de pagos, la consistencia importa muchísimo. En un contador de likes, puedes aceptar retrasos pequeños.

3. Haz estimaciones rápidas

No necesitas una calculadora perfecta. Necesitas números razonables.

Ejemplo:

• 10 millones de usuarios registrados.
• 1 millón de usuarios activos diarios.
• Cada usuario hace 20 lecturas al día.
• Eso son 20 millones de lecturas diarias.
• 20 millones dividido entre 86.400 segundos da unas 230 lecturas por segundo de media.
• Con picos, puedes multiplicar por 5 o 10.

Esto te ayuda a justificar decisiones. No es lo mismo diseñar para 100 requests por segundo que para 100.000.

4. Propón una arquitectura de alto nivel

Empieza simple:

• Cliente web o móvil.
• Load balancer.
• API Gateway o backend.
• Servicios principales.
• Base de datos.
• Caché.
• Cola de mensajes si hace falta.
• Almacenamiento de archivos si hay imágenes o vídeos.

No saltes a detalles finos demasiado pronto. Primero dibuja el mapa.

5. Diseña los datos

Aquí muchos candidatos flojean. Debes poder hablar de entidades, tablas, índices y relaciones.

Por ejemplo, para un sistema tipo Cabify:

• Users.
• Drivers.
• Rides.
• Locations.
• Payments.
• Ratings.

Luego explica qué datos se leen mucho, cuáles se escriben mucho y dónde pondrías índices.

6. Habla de cuellos de botella

Una entrevista buena no es la que no tiene fallos. Es la que reconoce riesgos.

Puedes decir:

• “El feed puede ser caro de calcular en tiempo real.”
• “La búsqueda por ubicación requiere índices geoespaciales.”
• “Subir imágenes puede saturar el backend si no usamos almacenamiento externo.”
• “Los pagos necesitan idempotencia para evitar cargos duplicados.”

Eso demuestra experiencia real.

7. Cierra con mejoras y observabilidad

No termines de golpe. Dedica unos minutos a operación:

• Logs.
• Métricas.
• Trazas.
• Alertas.
• Rate limiting.
• Backups.
• Disaster recovery.
• Tests de carga.

En empresas grandes, esto importa. En BBVA o Telefónica, un sistema que funciona en local pero no se puede operar en producción no sirve.

Ejemplo práctico: diseña un sistema tipo Glovo#

Vamos a practicar con un caso común: “Diseña un sistema de delivery tipo Glovo”.

No necesitas cubrir todo. Puedes acotar:

“Voy a diseñar el flujo principal: usuario busca restaurantes, hace un pedido, se asigna un repartidor, se sigue el estado en tiempo real y se procesa el pago.”

Requisitos funcionales

Podrías listar:

1. El usuario puede ver restaurantes cercanos.
2. El usuario puede crear un pedido.
3. El restaurante acepta o rechaza el pedido.
4. El sistema asigna un repartidor.
5. El usuario ve el estado del pedido.
6. El pago se procesa de forma segura.
7. El usuario recibe notificaciones.

Requisitos no funcionales

Aquí puedes decir:

• Baja latencia para búsqueda y seguimiento.
• Alta disponibilidad en horas punta.
• Consistencia fuerte en pagos y pedidos.
• Consistencia eventual en ubicación del repartidor.
• Tolerancia a fallos en notificaciones.

Este contraste es clave. No todos los datos necesitan el mismo nivel de consistencia.

Arquitectura inicial

Una arquitectura razonable:

• App móvil del cliente.
• App móvil del repartidor.
• Panel web del restaurante.
• API Gateway.
• Servicio de usuarios.
• Servicio de restaurantes.
• Servicio de pedidos.
• Servicio de pagos.
• Servicio de asignación de repartidores.
• Servicio de notificaciones.
• Base de datos relacional para pedidos y pagos.
• Redis para sesiones, caché y estados rápidos.
• Cola de mensajes para eventos.
• WebSocket o push notifications para seguimiento.

Podrías mencionar PostgreSQL para pedidos, porque las transacciones importan. Para ubicación de repartidores, Redis con datos geoespaciales puede ser buena opción.

Flujo de pedido

Explica paso a paso:

1. El cliente selecciona restaurante y productos.
2. El backend valida precios, disponibilidad y dirección.
3. Se crea un pedido en estado PENDING_PAYMENT.
4. Se llama al proveedor de pagos.
5. Si el pago va bien, el pedido pasa a PAID.
6. El restaurante recibe notificación.
7. Al aceptar, se publica un evento para asignar repartidor.
8. El servicio de asignación busca repartidores cercanos.
9. El repartidor acepta.
10. El cliente recibe actualizaciones.

Este nivel de detalle suele gustar. No es solo “uso microservicios”, es entender el negocio.

Problemas importantes

Aquí puedes ganar puntos:

• Pago duplicado: usa claves de idempotencia.
• Restaurante tarda en aceptar: define timeout.
• Repartidor se desconecta: reasignación automática.
• Muchos usuarios mirando el mapa: actualizaciones limitadas cada pocos segundos.
• Pico de viernes noche: autoscaling y colas.

Si quieres sonar más senior, añade costes:

“Para reducir coste, no enviaría ubicación cada 100 milisegundos. En la mayoría de casos, cada 2 o 5 segundos es suficiente.”

Eso muestra criterio de producto y tecnología.

Conceptos que sí o sí debes dominar#

No necesitas ser experto absoluto en todo. Pero hay piezas que aparecen una y otra vez.

Load balancer

Distribuye tráfico entre varias instancias del backend. Si una instancia cae, el tráfico va a otras.

En una entrevista puedes decir:

“Pondría un load balancer delante de servicios stateless para poder escalar horizontalmente.”

La palabra clave es stateless. Si tus servidores no guardan estado local crítico, puedes añadir o quitar instancias con menos dolor.

Caché

Redis o Memcached suelen aparecer mucho.

Úsala para:

• Datos leídos con frecuencia.
• Sesiones.
• Rate limiting.
• Resultados de consultas caras.
• Contadores aproximados.
• Feeds precalculados.

Pero no metas caché en todo. Debes hablar de invalidación.

Ejemplo:

“Cachearía perfiles públicos durante unos minutos. Si el usuario actualiza su perfil, invalidaría la clave correspondiente.”

Base de datos relacional vs NoSQL

PostgreSQL o MySQL son buenas para:

• Transacciones.
• Relaciones claras.
• Pagos.
• Pedidos.
• Inventario.
• Datos financieros.

NoSQL puede encajar para:

• Eventos masivos.
• Documentos flexibles.
• Time series.
• Feeds.
• Logs.
• Datos con escala extrema de escritura.

En entrevistas, elegir PostgreSQL como primera opción suele ser seguro si justificas bien.

Colas de mensajes

RabbitMQ, Kafka, SQS o Pub/Sub ayudan a desacoplar sistemas.

Úsalas para:

• Enviar emails.
• Procesar imágenes.
• Notificaciones.
• Eventos de pedido.
• Actualizar analíticas.
• Reintentos.

Ejemplo:

“Cuando se crea un pedido, publico un evento OrderCreated. El servicio de notificaciones y el de analítica lo consumen sin bloquear la respuesta al usuario.”

CDN y almacenamiento de archivos

Si diseñas algo con imágenes o vídeos, como Inditex online, Instagram o un marketplace, no sirvas archivos pesados desde tu backend.

Lo normal:

• Subir imagen a S3, GCS o similar.
• Guardar metadata en base de datos.
• Servir contenido mediante CDN.
• Generar thumbnails de forma asíncrona.

Esto reduce latencia y carga del backend.

Rate limiting

Protege tu sistema de abuso y picos raros.

Puedes aplicarlo por:

• IP.
• Usuario.
• API key.
• Tipo de endpoint.

Ejemplo:

“Para login limitaría intentos por IP y por usuario. Para endpoints públicos usaría límites más agresivos.”

Observabilidad

En 2026, decir “pondría logs” se queda corto. Mejor hablar de:

• Métricas de latencia p50, p95, p99.
• Tasa de errores.
• Trazas distribuidas.
• Dashboards.
• Alertas.
• Health checks.
• SLOs.

No hace falta profundizar mucho, pero sí demostrar que sabes operar producción.

Cómo responder si te quedas en blanco#

Te va a pasar alguna vez. No pasa nada.

Lo peor que puedes hacer es callarte y mirar al techo. En System Design, pensar en voz alta es parte del juego.

Usa frases de rescate:

• “Voy a empezar por una versión simple y luego la escalo.”
• “Asumo por ahora 1 millón de usuarios diarios, si te parece lo ajustamos.”
• “Hay dos opciones aquí, priorizar consistencia o latencia. Para este caso elegiría…”
• “No quiero meter complejidad antes de tiempo, empezaría con…”
• “Este punto puede ser cuello de botella, lo reviso después de definir el flujo principal.”

Estas frases te dan aire y muestran método.

También puedes volver al marco de 7 pasos:

1. Requisitos.
2. Escala.
3. APIs.
4. Datos.
5. Arquitectura.
6. Cuellos de botella.
7. Operación.

Cuando te pierdas, vuelve ahí.

Errores típicos que te hacen parecer menos senior#

Hay fallos que se repiten muchísimo.

Error 1: empezar diseñando microservicios sin requisitos

Si tu primera frase es “ponemos microservicios con Kafka y Kubernetes”, mala señal.

Mejor:

“Primero confirmo requisitos y escala. Si el sistema empieza pequeño, un modular monolith puede ser suficiente. Si crece por equipos o dominios, separaría servicios.”

Esto suena mucho más real.

Error 2: no hablar de datos

Puedes tener una arquitectura bonita, pero si no sabes dónde guardar datos, se cae.

Incluye siempre:

• Entidades principales.
• Base de datos elegida.
• Índices importantes.
• Lecturas y escrituras críticas.
• Consistencia necesaria.

Error 3: ignorar fallos

Los sistemas fallan. Los pagos fallan. Las redes fallan. Los proveedores externos fallan.

Di cómo reaccionas:

• Reintentos con backoff.
• Dead letter queue.
• Timeouts.
• Circuit breakers.
• Idempotencia.
• Alertas.

Error 4: diseñar para escala absurda sin motivo

No todo es Google. Si te piden un sistema interno para RRHH con 5.000 empleados, no necesitas Cassandra global multi-región.

En Telefónica o BBVA puede haber sistemas enormes, sí. Pero parte del seniority está en no sobrediseñar.

Error 5: no adaptar el nivel al rol

Si eres junior, se espera estructura y fundamentos. Si eres senior, se espera criterio, trade-offs y experiencia de producción.

Para puestos de €45k, quizá basta con buena base. Para €70k o €90k remoto, tendrás que hablar de escalado, resiliencia, costes, ownership y operación.

Preguntas clásicas de System Design en 2026#

Practica estas. No intentes memorizar respuestas, trabaja la estructura.

Nivel inicial o intermedio

• Diseña un acortador de URLs.
• Diseña un sistema de login.
• Diseña una API de comentarios.
• Diseña un sistema de notificaciones.
• Diseña un contador de visitas.
• Diseña un sistema de subida de imágenes.
• Diseña una agenda de citas.

Nivel senior

• Diseña WhatsApp.
• Diseña Twitter/X feed.
• Diseña Uber o Cabify.
• Diseña Glovo.
• Diseña un marketplace tipo Wallapop.
• Diseña un sistema de pagos.
• Diseña un sistema de reservas hoteleras.
• Diseña la web de Inditex en campaña de rebajas.

Nivel staff o principal

• Diseña una plataforma multi-región.
• Migra un monolito a servicios.
• Diseña un sistema de feature flags global.
• Diseña observabilidad para cientos de servicios.
• Diseña una plataforma de eventos interna.
• Reduce latencia p99 en una API crítica.
• Diseña un sistema anti-fraude en tiempo real.

Si estás empezando, no saltes directo a WhatsApp. Haz primero URL shortener, notificaciones y subida de imágenes. Son pequeños, pero enseñan casi todos los conceptos.

Plantilla de respuesta que puedes usar en entrevista#

Te dejo una plantilla que puedes repetir hasta que te salga natural.

Paso 1: acotar

“Voy a confirmar el alcance. Entiendo que necesitamos X, Y y Z. Dejaría fuera A y B para la primera versión, salvo que quieras incluirlo.”

Paso 2: requisitos

“Como requisitos no funcionales, priorizaría disponibilidad, latencia baja para lecturas y consistencia fuerte en las operaciones críticas.”

Paso 3: escala

“Asumo 10 millones de usuarios registrados y 1 millón activos diarios. Si cada uno hace 20 lecturas, hablamos de unos 20 millones de lecturas al día, con picos bastante superiores.”

Paso 4: arquitectura

“Empezaría con clientes móviles/web, un load balancer, servicios stateless, una base de datos relacional para datos transaccionales, Redis para caché y una cola para tareas asíncronas.”

Paso 5: datos

“Las entidades principales serían Users, Orders, Payments y Events. En Orders indexaría por user_id, status y created_at.”

Paso 6: flujos

“Para crear un pedido, validamos datos, creamos registro pendiente, procesamos pago con idempotency key, actualizamos estado y publicamos evento para notificaciones.”

Paso 7: riesgos

“Los puntos delicados son pagos duplicados, picos de tráfico y fallo del proveedor externo. Usaría timeouts, reintentos controlados, dead letter queue y alertas.”

Esta plantilla no te da una respuesta perfecta, pero evita que improvises desde cero.

Cómo practicar durante 30 días#

No necesitas estudiar ocho horas al día. Sí necesitas constancia.

Semana 1: fundamentos

Dedica 45 minutos al día a:

• HTTP y APIs REST.
• Bases de datos relacionales.
• Índices.
• Caché.
• Colas.
• Balanceadores.
• CDN.

Haz dibujos simples. Si no puedes dibujarlo, no lo entiendes todavía.

Semana 2: sistemas pequeños

Practica:

1. URL shortener.
2. Sistema de login.
3. Notificaciones.
4. Subida de imágenes.
5. Comentarios y likes.

Para cada uno, escribe:

• Requisitos.
• APIs.
• Modelo de datos.
• Arquitectura.
• Cuellos de botella.

Semana 3: sistemas medianos

Sube nivel:

• Marketplace.
• Delivery tipo Glovo.
• Reservas.
• Feed social.
• Chat básico.

Grábate explicando en voz alta durante 30 minutos. Da vergüenza, pero funciona.

Semana 4: simulacros

Haz entrevistas simuladas con alguien técnico. Si no tienes a nadie, usa un temporizador:

• 5 minutos para preguntas.
• 5 minutos para estimaciones.
• 10 minutos para arquitectura.
• 10 minutos para deep dive.
• 5 minutos para fallos y cierre.

Después revisa: ¿fuiste claro? ¿Saltaste a soluciones? ¿Olvidaste datos? ¿Mencionaste operación?

Qué decir según tu experiencia#

No todos deben sonar igual.

Si eres junior

Tu objetivo es mostrar orden.

Puedes decir:

“Empezaría simple con una API monolítica modular y una base de datos relacional. Añadiría caché o colas solo cuando aparezca un problema claro.”

Eso está muy bien para junior.

Si eres mid-level

Tu objetivo es mostrar autonomía.

Debes hablar de:

• Escala moderada.
• Índices.
• Caché.
• Tareas asíncronas.
• Separación por dominios.
• Tests y despliegue.

Si eres senior

Tu objetivo es mostrar criterio.

Incluye:

• Trade-offs.
• Coste operativo.
• Migraciones.
• Observabilidad.
• Fallos parciales.
• Seguridad.
• Consistencia.
• Experiencia de equipo.

Por ejemplo:

“No separaría pagos en un servicio independiente desde el día uno si el equipo es pequeño, pero sí aislaría bien el dominio y los contratos para poder extraerlo después.”

Eso suena a alguien que ha vivido producción.

Mini chuleta de decisiones rápidas#

Guárdate esto para repasar antes de la entrevista.

Si hay muchas lecturas

• Caché.
• CDN.
• Réplicas de lectura.
• Precomputación.
• Paginación.

Si hay muchas escrituras

• Colas.
• Batch processing.
• Particionado.
• Backpressure.
• Escrituras asíncronas donde se pueda.

Si hay archivos pesados

• Object storage.
• CDN.
• URLs firmadas.
• Procesamiento asíncrono.
• Thumbnails.

Si hay pagos

• Base relacional.
• Transacciones.
• Idempotencia.
• Auditoría.
• Logs seguros.
• Reconciliación.

Si hay ubicación en tiempo real

• Redis geospatial.
• WebSockets.
• Actualizaciones limitadas.
• Eventos.
• Tolerancia a datos algo antiguos.

Si hay feed

• Fanout on write.
• Fanout on read.
• Ranking.
• Caché.
• Paginación por cursor.
• Eventual consistency.

Cómo destacar frente a otros candidatos#

Muchos candidatos conocen los nombres de las tecnologías. Pocos conectan tecnología con negocio.

Si en una entrevista para Cabify dices que el matching conductor-pasajero debe priorizar distancia, disponibilidad, ETA y cancelaciones, estás pensando como producto.

Si en una entrevista para Inditex mencionas picos por rebajas, caché de catálogo, stock con consistencia cuidadosa y colas para pedidos, estás mostrando contexto real.

Si para BBVA hablas de auditoría, trazabilidad, seguridad, permisos, cumplimiento y consistencia en operaciones financieras, subes nivel.

Si para Telefónica hablas de alta disponibilidad, volumen, sistemas legacy y migraciones graduales, también.

La clave es no sonar como una lista de herramientas. Suena como alguien que entiende por qué cada pieza existe.

Cierre: empieza simple, piensa en voz alta y justifica#

System Design impresiona porque parece enorme. Pero en entrevista casi siempre se reduce a lo mismo: entender requisitos, diseñar una versión simple, detectar cuellos de botella y mejorar con criterio.

No necesitas dar la arquitectura perfecta. Necesitas demostrar que puedes construir sistemas útiles, mantenerlos vivos y tomar decisiones razonables bajo presión.

Si estás buscando puestos mejor pagados, especialmente a partir de €45k o €60k, prepara esta parte con la misma seriedad que tu CV. Y hablando de CV, antes de mandar más candidaturas, revisa si tu currículum pasa filtros ATS y presenta bien tu experiencia técnica con el ATS checker gratis de JobRise.