56 items with this tag.
Data models, capacity, communication, and recovery: a path through architecture decisions connected to concrete cases.
Modelos de datos, capacidad, comunicación y recuperación: un recorrido de decisiones de arquitectura conectado con casos concretos.
Concepts and experiments on state, persistence, communication, failures, and observability for building and operating reliable software systems.
Conceptos y experimentos sobre estado, persistencia, comunicación, fallos y observabilidad para construir y operar sistemas de software confiables.
Measure useful work, bound queues and budgets, and reject in time without transferring the burst to the database.
CDN design with cache keys, TTL, versions, and invalidation: accelerate delivery while preserving authorization, freshness, and origin protection.
Separate atomicity, isolation, visibility, and authority when protecting invariants across processes and stores.
Operation identity, atomic deduplication, retention, and recovery when a response is lost.
L4 and L7 load balancing with health checks, affinity, overload control, and draining: distribute traffic without confusing failover with atomicity.
Connect signals to business outcomes and verify concurrency, recovery, and boundaries through failure testing.
Durable event publication, repeatable relays, and rebuilding views without promising atomicity across stores.
A hypothetical payments and settlement case connecting a ledger, real-time and batch processing, three data centers, AWS, and verifiable SRE operations.
A self-contained payments and settlement review: invariants, hybrid authority, batch cycles, diagnosis, secrets, and verifiable recovery with SRE.
What a write acknowledgment confirms, how authority changes, and how to verify recovery across replicas, zones, and regions.
Deadlines, recovery, and fencing to coordinate attempts without confusing expiry with cancellation or absence of an effect.
Medir trabajo útil, acotar colas y presupuestos, y rechazar a tiempo sin trasladar el pico a la base de datos.
Diseño de CDN con cache keys, TTL, versiones e invalidación: acelerar entregas conservando autorización, frescura y protección del origen.
Separar atomicidad, aislamiento, visibilidad y autoridad al proteger invariantes entre procesos y almacenes.
Identidad de operación, deduplicación atómica, retención y recuperación cuando una respuesta se pierde.
Balanceo L4 y L7 con health checks, afinidad, control de sobrecarga y draining: repartir tráfico sin confundir failover con atomicidad.
Relacionar señales con resultados de negocio y comprobar concurrencia, recuperación y límites mediante ensayos de fallos.
Publicación durable de eventos, relay repetible y reconstrucción de vistas sin prometer atomicidad entre almacenes.
Un caso hipotético de pagos y liquidación que conecta ledger, procesamiento real-time y batch, tres centros de datos, AWS y operación SRE verificable.
Un repaso autocontenido de pagos y liquidación: invariantes, autoridad híbrida, ciclos batch, diagnóstico, secretos y recuperación verificable con SRE.
Qué confirma una escritura, cómo cambia la autoridad y cómo comprobar recuperación entre réplicas, zonas y regiones.
Plazos, recuperación y fencing para coordinar intentos sin confundir vencimiento con cancelación o ausencia de efecto.
How to choose between local transactions, Two-Phase Commit, and Saga, and the guarantees provided by orchestration, compensations, and the outbox.
Design API contracts with resources, inputs, HTTP methods, pagination, authorization, and retries that preserve business rules.
Cache design with cache-aside and Redis: latency, capacity, invalidation, stampedes, hot keys, and recovery without overloading the database.
How consistent hashing assigns keys: rings, node changes, virtual positions, hotspots, and actual data movement.
Model data around access patterns and invariants: entities, keys, constraints, indexes, normalization, and locality when distributing it.
Dockerfiles, images, and containers: builds, distribution, caching, persistence, and isolation limits when running applications and agents.
A practical path through Hello Interview's Delivery Framework: requirements, entities, APIs, basic design, and case-driven deep dives.
How to choose between RabbitMQ task queues and Kafka event streams, considering routing, retention, replay, delivery, and idempotency.
Message queues in system design: asynchronous work, capacity, backpressure, partitions, ordering, idempotency, and recovery with a DLQ.
Separate files and metadata with object storage: keys, durability, direct uploads, signed URLs, multipart, and verifiable finalization.
Keys, data structures, and Redis Cluster: slots, hash tags, operations, hotspots, expiration, and persistence and recovery limits.
How to distribute data across shards: keys, locality, hotspots, queries, transactions, and migrations with defined routes and owners.
Cómo elegir entre transacciones locales, Two-Phase Commit y Saga, y qué garantías aportan la orquestación, las compensaciones y la outbox.
Diseñar contratos de API con recursos, entradas, métodos HTTP, paginación, autorización y reintentos que preserven las reglas del negocio.
Diseño de cachés con cache-aside y Redis: latencia, capacidad, invalidación, stampede, claves calientes y recuperación sin saturar la base de datos.
Cómo asignar claves con consistent hashing: anillo, cambios de nodos, posiciones virtuales, hotspots y movimiento real de datos.
Modelar datos desde sus accesos e invariantes: entidades, claves, restricciones, índices, normalización y localidad al distribuirlos.
Dockerfile, imágenes y contenedores: construcción, distribución, caché, persistencia y límites de aislamiento al ejecutar aplicaciones y agentes.
Un recorrido práctico del Delivery Framework de Hello Interview: requisitos, entidades, APIs, diseño básico y deep dives guiados por el caso.
Cómo elegir entre colas de tareas con RabbitMQ y flujos de eventos con Kafka, considerando enrutamiento, retención, replay, entrega e idempotencia.
Colas de mensajes en diseño de sistemas: trabajo asíncrono, capacidad, backpressure, particiones, orden, idempotencia y recuperación con DLQ.
Separar archivos y metadatos con object storage: claves, durabilidad, cargas directas, URLs firmadas, multipart y finalización verificable.
Claves, estructuras y Redis Cluster: slots, hash tags, operaciones, hotspots, expiración y límites de persistencia y recuperación.
Cómo repartir datos entre shards: claves, localidad, hotspots, consultas, transacciones y migraciones con rutas y propietarios definidos.
Designing a distributed rate limiter with Token Bucket, shared Redis state, and decisions about scalability, latency, and failures.
Designing a ticketing system with temporary holds, payments, consistent inventory, event search, and a virtual queue for high-demand sales.
Diseño de un limitador de tasa distribuido con Token Bucket, estado compartido en Redis y decisiones sobre escalabilidad, latencia y fallos.
Diseño de un sistema de boletaje con reservas temporales, pagos, inventario consistente, búsqueda de eventos y una cola virtual para ventas masivas.
Por qué conviene diseñar primero sistemas naive y manuales antes de automatizar. Como en el deporte: hay que hacerlo ineficiente antes de optimizar.
Why you should design naive, manual systems first before automation. Like learning a sport - you need to do it inefficiently before you can optimize.