Tema: system-design
-
Recorrido por un servicio de carga de archivos: tickets directos al almacenamiento, escaneo asíncrono y cuotas
Un recorrido de diseño para cargas que evitan los servidores de aplicación: un ticket que reserva cuota y devuelve una URL de carga firmada, un paso de finalización que verifica el objeto almacenado, un worker de escaneo que lo promueve o lo elimina, reglas de ciclo de vida para las cargas abandonadas, y un modelo de estado que explica cada objeto almacenado.
-
Recorrido por un servicio de notificaciones: canales, preferencias, intentos de entrega y reintentos
Un recorrido de diseño para un servicio de notificaciones multicanal: una API de ingesta con clave de idempotencia, un enrutador que expande una notificación en entregas por canal tras comprobar las preferencias, colas y calendarios de reintento por canal, manejo de callbacks para tokens inválidos, y qué dejar para después.
-
Los servicios de enlaces cortos con identificadores secuenciales reciben más solicitudes de enumeración que los servicios con identificadores aleatorios
Hipótesis: un acortador de URL cuyas claves son un contador codificado en base62 permite que cualquiera recorra todos los enlaces, mientras que las claves aleatorias de longitud fija hacen que la mayoría de los intentos fallen; la propuesta es que los servicios secuenciales presentan una proporción mayor de solicitudes de claves existentes procedentes de clientes que nunca recibieron el enlace, y que la proporción de respuestas 404 no distingue entre ambos casos.
-
Recorrido por un acortador de URL: generación de claves, estado de redirección y controles contra abusos
Un recorrido de diseño para un acortador de URL: claves aleatorias en base62 con reintento ante colisiones, una ruta de redirección que toca una sola caché y un único almacén, 302 en lugar de 301 cuando los destinos deben seguir siendo revocables y contables, comprobaciones contra abusos en la creación, y una lista de lo que no conviene construir primero.
-
Recorrido guiado por un planificador de trabajos: leases, reintentos, claves de idempotencia y una tabla de cola
Un recorrido de diseño para trabajos en segundo plano y programaciones recurrentes sobre una tabla de base de datos: los workers reclaman filas con FOR UPDATE SKIP LOCKED bajo un lease, los fallos reprograman con backoff hasta un máximo, una clave de idempotencia única convierte los encolados duplicados en operaciones sin efecto, y se pospone un message broker hasta que la antigüedad de la cola indique lo contrario.
-
Recorrido de diseño de la búsqueda de documentos sobre un corpus: canalización de indexación, permisos y reindexación
Un recorrido de diseño para la búsqueda sobre documentos que residen en un sistema de registro: un índice derivado y reconstruible alimentado por eventos de cambio, claves de ACL indexadas como campos para que el filtrado ocurra antes del ranking, índices versionados que se cambian mediante un alias, un reconciliador que detecta desviaciones (drift), y una lista de lo que se debe posponer.
-
Recorrido por una tabla de clasificación: eventos de puntuación, un conjunto ordenado derivado y clasificaciones reconstruibles
Un recorrido de diseño para tablas de clasificación: eventos de puntuación con autoridad del servidor y una clave de idempotencia como fuente de verdad, un conjunto ordenado por cada período de la tabla como índice derivado que responde a consultas de top-N y de la posición de un único miembro, reglas de desempate codificadas en la puntuación, límites de período enrutados por el momento en que ocurrió el evento, y reconstrucciones como práctica habitual.
-
¿En qué punto sustituyen los equipos una tabla de cola de PostgreSQL por un message broker, y qué lo desencadenó?
Pregunta abierta: la documentación de PostgreSQL respalda SKIP LOCKED para varios consumidores sobre una tabla que actúa como cola, y las guías de diseño recomiendan empezar ahí; ¿qué desencadenantes (antigüedad de la cola, contención de bloqueos, hinchazón de la tabla, necesidades de fan-out, carga operativa) han provocado realmente un cambio a un broker, con qué volúmenes, y cuántos sistemas nunca cambiaron?
-
Diseño de un almacén de sesiones: ids opacos, dos caducidades, revocación y comportamiento ante caídas
Guía de diseño del almacén del lado del servidor que respalda una cookie de sesión: filas indexadas por el hash del id, caducidad por inactividad y absoluta como configuración, escrituras limitadas de last-seen, un índice por usuario para cerrar sesión en todas partes, comportamiento de fallo cerrado ante una caída del almacén y funciones que conviene posponer.
-
Recorrido de diseño de un servicio de feature flags: conjuntos de reglas, evaluación local y despliegues porcentuales estables
Recorrido de diseño de un servicio de flags: definiciones servidas como un conjunto de reglas versionado por entorno, SDK que almacenan en cache y evalúan localmente, un contexto de evaluación para la segmentación, reparto por hash estable para que los usuarios no cambien de variante durante un despliegue, valores preevaluados para clientes no confiables e informes que detectan flags muertos.
-
Recorrido por un servicio de configuración: versiones inmutables, despliegue por etapas y última versión válida conocida
Recorrido de diseño para distribuir configuración en tiempo de ejecución: versiones inmutables y validadas; un controlador de despliegue que avanza cohortes elegidas con un hash estable por etapas, con tiempo de espera y condición de detención; clientes que consultan o vigilan cambios, aplican de forma atómica y conservan un archivo de última versión válida conocida; y lo que se deja fuera a propósito.
-
Guía de diseño de un sistema de comentarios: hilos, estados de moderación y contenido re-renderizable
Guía de diseño para comentarios en hilo con moderación: el texto fuente es la fuente de verdad y se renderiza en lectura con un sanitizador actualizado, con ruta materializada y límite de profundidad, estados pending/visible/hidden/removed que conservan la forma del hilo, auditoría de reportes y acciones de moderación, y funciones que se dejan deliberadamente para más adelante.
Legible por máquina: JSON