{"schemaVersion":1,"id":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation","title":"Arquitectura Basada en Celdas: Aislamiento de Radio de Explosión, Shuffle Sharding y Cómo AWS y Slack Reducen Dominios de Fallo","description":"Un vistazo técnico profundo a la arquitectura basada en celdas, cómo aislar fallos a una fracción de usuarios a través de celdas independientes, shuffle sharding, enrutamiento de celdas y patrones de implementación real extraídos de AWS, Slack y sistemas de producción.","language":"es","datePublished":"2025-12-06","dateModified":null,"contentFormat":"text/markdown","content":"Architecture\n\n# Arquitectura Basada en Celdas: Aislamiento de Radio de Explosión, Shuffle Sharding y Cómo AWS y Slack Reducen Dominios de Fallo\n\n2025-12-065 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/cell-based-architecture-blast-radius-isolation>)\n\n## La Idea Central\n\nLa arquitectura basada en celdas divide tu sistema en unidades independientes y autónomas llamadas celdas. Cada celda sirve un subconjunto de tenants y contiene toda la infraestructura necesaria para operar independientemente, sus propias bases de datos, caches, colas y compute.\n\n```\n ┌─────────────┐\n │ Router │\n │ (Asignación│\n │ de Celdas) │\n └──────┬──────┘\n │\n ┌────────────┼────────────┐\n │ │ │\n ┌─────▼─────┐ ┌───▼─────┐ ┌───▼─────┐\n │ Celda A │ │ Celda B │ │ Celda C │\n │ ┌───────┐ │ │┌───────┐│ │┌───────┐│\n │ │API │ │ ││API ││ ││API ││\n │ │DB │ │ ││DB ││ ││DB ││\n │ │Cache │ │ ││Cache ││ ││Cache ││\n │ │Cola │ │ ││Cola ││ ││Cola ││\n │ └───────┘ │ │└───────┘│ │└───────┘│\n └───────────┘ └─────────┘ └─────────┘\n```\n\nLa propiedad crítica: las celdas no comparten nada. Si la base de datos de la Celda A se cae, las celdas B y C siguen operando.\n\n## Enrutamiento de Celdas\n\n```javascript\nconst CELL_ENDPOINTS = {\n 0: 'https://cell-a.internal.example.com',\n 1: 'https://cell-b.internal.example.com',\n 2: 'https://cell-c.internal.example.com',\n 3: 'https://cell-d.internal.example.com',\n};\n\nfunction assignCell(tenantId) {\n const hash = fnv1a(tenantId);\n return hash % Object.keys(CELL_ENDPOINTS).length;\n}\n\nexport default {\n async fetch(request) {\n const tenantId = extractTenantId(request);\n const cellIndex = assignCell(tenantId);\n const cellUrl = CELL_ENDPOINTS[cellIndex];\n\n const cellRequest = new Request(\n `${cellUrl}${new URL(request.url).pathname}`,\n request,\n );\n\n try {\n const response = await fetch(cellRequest, { cf: { timeout: 10000 } });\n response.headers.set('X-Cell', `cell-${cellIndex}`);\n return response;\n } catch (error) {\n return new Response('Servicio temporalmente no disponible', { status: 503 });\n }\n },\n};\n```\n\n## Shuffle Sharding: Reduciendo el Radio de Explosión\n\n```python\nimport hashlib\nimport random\n\ndef shuffle_shard(tenant_id, num_cells, shard_size=2):\n seed = int(hashlib.sha256(tenant_id.encode()).hexdigest(), 16)\n rng = random.Random(seed)\n cells = list(range(num_cells))\n rng.shuffle(cells)\n return cells[:shard_size]\n\n# Con 8 celdas y shards de 2 celdas:\n# - Fallo de una celda afecta: 25% de tenants como máximo\n# - Ese es tenants hacen failover a su celda secundaria\n# - Dos fallos simultáneos afectan: ~3.6% de tenants\n```\n\n[AWS](<https://aws.amazon.com/>) Route 53 usa este patrón. Cada zona DNS se asigna a 4 de sus 2.048 shards virtuales. La probabilidad de que un \"vecino ruidoso\" (un DDoS en una zona) afecte a otra zona específica es insignificantemente pequeña.\n\n## Infraestructura de Celdas con Terraform\n\n```hcl\nvariable \"cell_id\" { type = string }\nvariable \"cell_index\" { type = number }\n\nresource \"aws_vpc\" \"cell\" {\n cidr_block = \"10.${var.cell_index}.0.0/16\"\n tags = { Name = \"cell-${var.cell_id}\" }\n}\n\nresource \"aws_rds_cluster\" \"cell_db\" {\n cluster_identifier = \"cell-${var.cell_id}-db\"\n engine = \"aurora-postgresql\"\n engine_version = \"16.1\"\n tags = { Cell = var.cell_id }\n}\n\nresource \"aws_elasticache_replication_group\" \"cell_cache\" {\n replication_group_id = \"cell-${var.cell_id}-redis\"\n node_type = \"cache.r7g.large\"\n num_cache_clusters = 2\n tags = { Cell = var.cell_id }\n}\n```\n\nLos VPCs están aislados, las celdas no pueden comunicarse accidentalmente entre sí. Esto es deliberado.\n\n## Estrategia de Deployment: Celdas Canary\n\n```yaml\nstages:\n - name: canary-cell\n cells: [\"cell-a\"]\n validation:\n - health_check: 5m\n - error_rate: < 0.1%\n - latency_p99: < 200ms\n rollback_on_failure: true\n\n - name: second-wave\n cells: [\"cell-b\"]\n depends_on: canary-cell\n delay: 15m\n\n - name: remaining\n cells: [\"cell-c\", \"cell-d\"]\n depends_on: second-wave\n delay: 30m\n```\n\nAsí es exactamente como un incidente de migración de base de datos funciona con celdas: la migración corre en Celda A, se rompe, se hace rollback de Celda A, y las celdas B/C/D nunca ven la migración mala. En vez de 45 minutos de downtime total, son 5 minutos de outage parcial para un cuarto de los usuarios.\n\n## Monitoreo Por Celda\n\n```yaml\ngroups:\n - name: cell_metrics\n rules:\n - record: cell:request_rate:5m\n expr: sum(rate(http_requests_total{job=\"api\"}[5m])) by (cell)\n - record: cell:error_rate:5m\n expr: |\n sum(rate(http_requests_total{status=~\"5..\"}[5m])) by (cell)\n / sum(rate(http_requests_total[5m])) by (cell)\n - name: cell_alerts\n rules:\n - alert: CellHighErrorRate\n expr: cell:error_rate:5m > 0.01\n for: 5m\n labels:\n severity: critical\n```\n\nLa label ` cell ` en cada métrica no es negociable. Sin ella, no es posible distinguir si un spike de error rate es un problema global o de una sola celda.\n\n## Trade-offs y Costos Operacionales\n\n**Costo**: Correr N copias de todo significa que 4 celdas es aproximadamente 4x el costo de base de datos. En la práctica, las celdas agregan alrededor de 40% a los costos de infraestructura.\n\n**Complejidad operacional**: Cada procedimiento operacional necesita un paso de \"¿qué celda?\". Migraciones de base de datos, cambios de schema, actualizaciones de config, todo necesita ser cell-aware.\n\n**Migración de datos**: Mover un tenant entre celdas es la operación más difícil. Requiere una pausa de escritura coordinada, copia de datos y actualización de routing.\n\n**Features globales**: Algunas cosas inherentemente cruzan celdas, búsqueda global, analytics cross-tenant. Necesitan una capa de agregación separada que lee de todas las celdas.\n\n## Para Cerrar\n\nLa arquitectura basada en celdas es la opción nuclear para aislamiento de radio de explosión. Funciona, los sistemas pasan de \"un mal deployment tumba todo\" a \"un mal deployment afecta 25% de usuarios por 5 minutos\", pero el costo operacional es real.\n\nSe recomienda comenzar de forma simple: circuit breakers, bulkheads, deployments multi-AZ. Conviene avanzar hacia celdas cuando un dominio de fallo único que afecta a todos los usuarios se convierte en un riesgo existencial para el negocio. Al implementar celdas, es recomendable comenzar con 4, mantenerlas verdaderamente independientes, e invertir fuertemente en observabilidad por celda.\n\nLa arquitectura es la parte fácil. Convivir con ella es la parte difícil.\n\n## Preguntas frecuentes\n\n### ¿Cómo difiere la arquitectura basada en celdas de los microservicios?\n\nLos microservicios dividen por función, un servicio para auth, otro para pagos. La arquitectura basada en celdas divide por tenant. Cada celda corre TODOS los servicios para un SUBCONJUNTO de tenants. La diferencia clave es el boundary de fallo: un fallo de microservicio afecta a todos los usuarios de esa función, mientras un fallo de celda afecta solo a usuarios asignados a esa celda.\n\n### ¿Qué es shuffle sharding y por qué importa?\n\nShuffle sharding asigna cada tenant a un subconjunto random de celdas (típicamente 2 de N). Si la celda A falla, solo los tenants cuyo shard set incluye la celda A son afectados, y ese es tenants hacen failover a su segunda celda. Con 8 celdas y shards de 2 celdas, cualquier fallo de una celda afecta solo al 25% de tenants, y la mayoría se recupera automáticamente.\n\n### ¿Cuándo la arquitectura basada en celdas es overkill?\n\nSi tu sistema tiene menos de 1000 tenants, sirve menos de 10K requests/segundo, o tiene un equipo menor a 5 ingenieros. El overhead operacional de mantener múltiples stacks de infraestructura independientes es significativo. Considerá aislamiento de fallos más simple primero, multi-región active-active, o simplemente circuit breaking exhaustivo.\n\n## Tips\n\n1. **Tip:** Se recomienda comenzar con 4 celdas, no 40. Cada celda es una copia completa de tu infraestructura, networking, bases de datos, caches, colas. Más celdas significa mejor aislamiento pero exponencialmente más overhead operacional. Empezar con 8 y volver a 4 es común una vez que la carga de monitoreo se vuelve insostenible para equipos pequeños.\n2. **Tip:** La asignación de celdas debe ser determinista y consistente, es necesario aplicar hash al tenant ID, no al request. Si el mismo usuario accede a diferentes celdas en diferentes requests, se pierde localidad de datos y eficiencia de cache. Se recomienda utilizar ` cell = tenantId % numCells ` o consistent hashing.\n3. **Tip:** Siempre mantener una celda como 'celda canary' que recibe deployments primero. Si el deployment rompe la canary, contuviste el radio de explosión a ~25% de usuarios (con 4 celdas) en vez de 100%. Este enfoque puede prevenir que una mala migración corrompa registros de pagos en todo el sistema.\n4. **Tip:** No compartas bases de datos entre celdas. Bases de datos compartidas son dominios de fallo compartidos. Si absolutamente se necesita compartir estado (como un directorio global de usuarios), configurarlo como read-only desde las celdas y write-only desde un control plane separado.\n\n- cell-based-architecture\n- blast-radius\n- shuffle-sharding\n- aislamiento-de-fallos\n- sistemas-distribuidos\n- aws\n- slack\n- resiliencia\n- alta-disponibilidad\n- arquitectura\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)","headings":[{"level":1,"text":"Arquitectura Basada en Celdas: Aislamiento de Radio de Explosión, Shuffle Sharding y Cómo AWS y Slack Reducen Dominios de Fallo","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#title"},{"level":2,"text":"La Idea Central","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#la-idea-central"},{"level":2,"text":"Enrutamiento de Celdas","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#enrutamiento-de-celdas"},{"level":2,"text":"Shuffle Sharding: Reduciendo el Radio de Explosión","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#shuffle-sharding-reduciendo-el-radio-de-explosin"},{"level":2,"text":"Infraestructura de Celdas con Terraform","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#infraestructura-de-celdas-con-terraform"},{"level":2,"text":"Estrategia de Deployment: Celdas Canary","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#estrategia-de-deployment-celdas-canary"},{"level":2,"text":"Monitoreo Por Celda","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#monitoreo-por-celda"},{"level":2,"text":"Trade-offs y Costos Operacionales","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#trade-offs-y-costos-operacionales"},{"level":2,"text":"Para Cerrar","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#para-cerrar"},{"level":2,"text":"Preguntas frecuentes","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#questions"},{"level":3,"text":"¿Cómo difiere la arquitectura basada en celdas de los microservicios?","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#question-1"},{"level":3,"text":"¿Qué es shuffle sharding y por qué importa?","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#question-2"},{"level":3,"text":"¿Cuándo la arquitectura basada en celdas es overkill?","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#question-3"},{"level":2,"text":"Tips","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#article-tips"}],"sections":[{"heading":"Arquitectura Basada en Celdas: Aislamiento de Radio de Explosión, Shuffle Sharding y Cómo AWS y Slack Reducen Dominios de Fallo","level":1,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation","content":"Architecture"},{"heading":"Arquitectura Basada en Celdas: Aislamiento de Radio de Explosión, Shuffle Sharding y Cómo AWS y Slack Reducen Dominios de Fallo","level":1,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#title","content":"2025-12-065 min lectura\n\nLucio Durán\nEngineering Manager & AI Solutions Architect\n\nTambién disponible en: [English](<https://lucioduran.com/blog/cell-based-architecture-blast-radius-isolation>)"},{"heading":"La Idea Central","level":2,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#la-idea-central","content":"La arquitectura basada en celdas divide tu sistema en unidades independientes y autónomas llamadas celdas. Cada celda sirve un subconjunto de tenants y contiene toda la infraestructura necesaria para operar independientemente, sus propias bases de datos, caches, colas y compute.\n\n```\n ┌─────────────┐\n │ Router │\n │ (Asignación│\n │ de Celdas) │\n └──────┬──────┘\n │\n ┌────────────┼────────────┐\n │ │ │\n ┌─────▼─────┐ ┌───▼─────┐ ┌───▼─────┐\n │ Celda A │ │ Celda B │ │ Celda C │\n │ ┌───────┐ │ │┌───────┐│ │┌───────┐│\n │ │API │ │ ││API ││ ││API ││\n │ │DB │ │ ││DB ││ ││DB ││\n │ │Cache │ │ ││Cache ││ ││Cache ││\n │ │Cola │ │ ││Cola ││ ││Cola ││\n │ └───────┘ │ │└───────┘│ │└───────┘│\n └───────────┘ └─────────┘ └─────────┘\n```\n\nLa propiedad crítica: las celdas no comparten nada. Si la base de datos de la Celda A se cae, las celdas B y C siguen operando."},{"heading":"Enrutamiento de Celdas","level":2,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#enrutamiento-de-celdas","content":"```javascript\nconst CELL_ENDPOINTS = {\n 0: 'https://cell-a.internal.example.com',\n 1: 'https://cell-b.internal.example.com',\n 2: 'https://cell-c.internal.example.com',\n 3: 'https://cell-d.internal.example.com',\n};\n\nfunction assignCell(tenantId) {\n const hash = fnv1a(tenantId);\n return hash % Object.keys(CELL_ENDPOINTS).length;\n}\n\nexport default {\n async fetch(request) {\n const tenantId = extractTenantId(request);\n const cellIndex = assignCell(tenantId);\n const cellUrl = CELL_ENDPOINTS[cellIndex];\n\n const cellRequest = new Request(\n `${cellUrl}${new URL(request.url).pathname}`,\n request,\n );\n\n try {\n const response = await fetch(cellRequest, { cf: { timeout: 10000 } });\n response.headers.set('X-Cell', `cell-${cellIndex}`);\n return response;\n } catch (error) {\n return new Response('Servicio temporalmente no disponible', { status: 503 });\n }\n },\n};\n```"},{"heading":"Shuffle Sharding: Reduciendo el Radio de Explosión","level":2,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#shuffle-sharding-reduciendo-el-radio-de-explosin","content":"```python\nimport hashlib\nimport random\n\ndef shuffle_shard(tenant_id, num_cells, shard_size=2):\n seed = int(hashlib.sha256(tenant_id.encode()).hexdigest(), 16)\n rng = random.Random(seed)\n cells = list(range(num_cells))\n rng.shuffle(cells)\n return cells[:shard_size]\n\n# Con 8 celdas y shards de 2 celdas:\n# - Fallo de una celda afecta: 25% de tenants como máximo\n# - Ese es tenants hacen failover a su celda secundaria\n# - Dos fallos simultáneos afectan: ~3.6% de tenants\n```\n\n[AWS](<https://aws.amazon.com/>) Route 53 usa este patrón. Cada zona DNS se asigna a 4 de sus 2.048 shards virtuales. La probabilidad de que un \"vecino ruidoso\" (un DDoS en una zona) afecte a otra zona específica es insignificantemente pequeña."},{"heading":"Infraestructura de Celdas con Terraform","level":2,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#infraestructura-de-celdas-con-terraform","content":"```hcl\nvariable \"cell_id\" { type = string }\nvariable \"cell_index\" { type = number }\n\nresource \"aws_vpc\" \"cell\" {\n cidr_block = \"10.${var.cell_index}.0.0/16\"\n tags = { Name = \"cell-${var.cell_id}\" }\n}\n\nresource \"aws_rds_cluster\" \"cell_db\" {\n cluster_identifier = \"cell-${var.cell_id}-db\"\n engine = \"aurora-postgresql\"\n engine_version = \"16.1\"\n tags = { Cell = var.cell_id }\n}\n\nresource \"aws_elasticache_replication_group\" \"cell_cache\" {\n replication_group_id = \"cell-${var.cell_id}-redis\"\n node_type = \"cache.r7g.large\"\n num_cache_clusters = 2\n tags = { Cell = var.cell_id }\n}\n```\n\nLos VPCs están aislados, las celdas no pueden comunicarse accidentalmente entre sí. Esto es deliberado."},{"heading":"Estrategia de Deployment: Celdas Canary","level":2,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#estrategia-de-deployment-celdas-canary","content":"```yaml\nstages:\n - name: canary-cell\n cells: [\"cell-a\"]\n validation:\n - health_check: 5m\n - error_rate: < 0.1%\n - latency_p99: < 200ms\n rollback_on_failure: true\n\n - name: second-wave\n cells: [\"cell-b\"]\n depends_on: canary-cell\n delay: 15m\n\n - name: remaining\n cells: [\"cell-c\", \"cell-d\"]\n depends_on: second-wave\n delay: 30m\n```\n\nAsí es exactamente como un incidente de migración de base de datos funciona con celdas: la migración corre en Celda A, se rompe, se hace rollback de Celda A, y las celdas B/C/D nunca ven la migración mala. En vez de 45 minutos de downtime total, son 5 minutos de outage parcial para un cuarto de los usuarios."},{"heading":"Monitoreo Por Celda","level":2,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#monitoreo-por-celda","content":"```yaml\ngroups:\n - name: cell_metrics\n rules:\n - record: cell:request_rate:5m\n expr: sum(rate(http_requests_total{job=\"api\"}[5m])) by (cell)\n - record: cell:error_rate:5m\n expr: |\n sum(rate(http_requests_total{status=~\"5..\"}[5m])) by (cell)\n / sum(rate(http_requests_total[5m])) by (cell)\n - name: cell_alerts\n rules:\n - alert: CellHighErrorRate\n expr: cell:error_rate:5m > 0.01\n for: 5m\n labels:\n severity: critical\n```\n\nLa label ` cell ` en cada métrica no es negociable. Sin ella, no es posible distinguir si un spike de error rate es un problema global o de una sola celda."},{"heading":"Trade-offs y Costos Operacionales","level":2,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#trade-offs-y-costos-operacionales","content":"**Costo**: Correr N copias de todo significa que 4 celdas es aproximadamente 4x el costo de base de datos. En la práctica, las celdas agregan alrededor de 40% a los costos de infraestructura.\n\n**Complejidad operacional**: Cada procedimiento operacional necesita un paso de \"¿qué celda?\". Migraciones de base de datos, cambios de schema, actualizaciones de config, todo necesita ser cell-aware.\n\n**Migración de datos**: Mover un tenant entre celdas es la operación más difícil. Requiere una pausa de escritura coordinada, copia de datos y actualización de routing.\n\n**Features globales**: Algunas cosas inherentemente cruzan celdas, búsqueda global, analytics cross-tenant. Necesitan una capa de agregación separada que lee de todas las celdas."},{"heading":"Para Cerrar","level":2,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#para-cerrar","content":"La arquitectura basada en celdas es la opción nuclear para aislamiento de radio de explosión. Funciona, los sistemas pasan de \"un mal deployment tumba todo\" a \"un mal deployment afecta 25% de usuarios por 5 minutos\", pero el costo operacional es real.\n\nSe recomienda comenzar de forma simple: circuit breakers, bulkheads, deployments multi-AZ. Conviene avanzar hacia celdas cuando un dominio de fallo único que afecta a todos los usuarios se convierte en un riesgo existencial para el negocio. Al implementar celdas, es recomendable comenzar con 4, mantenerlas verdaderamente independientes, e invertir fuertemente en observabilidad por celda.\n\nLa arquitectura es la parte fácil. Convivir con ella es la parte difícil."},{"heading":"Preguntas frecuentes","level":2,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#questions","content":""},{"heading":"¿Cómo difiere la arquitectura basada en celdas de los microservicios?","level":3,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#question-1","content":"Los microservicios dividen por función, un servicio para auth, otro para pagos. La arquitectura basada en celdas divide por tenant. Cada celda corre TODOS los servicios para un SUBCONJUNTO de tenants. La diferencia clave es el boundary de fallo: un fallo de microservicio afecta a todos los usuarios de esa función, mientras un fallo de celda afecta solo a usuarios asignados a esa celda."},{"heading":"¿Qué es shuffle sharding y por qué importa?","level":3,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#question-2","content":"Shuffle sharding asigna cada tenant a un subconjunto random de celdas (típicamente 2 de N). Si la celda A falla, solo los tenants cuyo shard set incluye la celda A son afectados, y ese es tenants hacen failover a su segunda celda. Con 8 celdas y shards de 2 celdas, cualquier fallo de una celda afecta solo al 25% de tenants, y la mayoría se recupera automáticamente."},{"heading":"¿Cuándo la arquitectura basada en celdas es overkill?","level":3,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#question-3","content":"Si tu sistema tiene menos de 1000 tenants, sirve menos de 10K requests/segundo, o tiene un equipo menor a 5 ingenieros. El overhead operacional de mantener múltiples stacks de infraestructura independientes es significativo. Considerá aislamiento de fallos más simple primero, multi-región active-active, o simplemente circuit breaking exhaustivo."},{"heading":"Tips","level":2,"url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#article-tips","content":"1. **Tip:** Se recomienda comenzar con 4 celdas, no 40. Cada celda es una copia completa de tu infraestructura, networking, bases de datos, caches, colas. Más celdas significa mejor aislamiento pero exponencialmente más overhead operacional. Empezar con 8 y volver a 4 es común una vez que la carga de monitoreo se vuelve insostenible para equipos pequeños.\n2. **Tip:** La asignación de celdas debe ser determinista y consistente, es necesario aplicar hash al tenant ID, no al request. Si el mismo usuario accede a diferentes celdas en diferentes requests, se pierde localidad de datos y eficiencia de cache. Se recomienda utilizar ` cell = tenantId % numCells ` o consistent hashing.\n3. **Tip:** Siempre mantener una celda como 'celda canary' que recibe deployments primero. Si el deployment rompe la canary, contuviste el radio de explosión a ~25% de usuarios (con 4 celdas) en vez de 100%. Este enfoque puede prevenir que una mala migración corrompa registros de pagos en todo el sistema.\n4. **Tip:** No compartas bases de datos entre celdas. Bases de datos compartidas son dominios de fallo compartidos. Si absolutamente se necesita compartir estado (como un directorio global de usuarios), configurarlo como read-only desde las celdas y write-only desde un control plane separado.\n\n- cell-based-architecture\n- blast-radius\n- shuffle-sharding\n- aislamiento-de-fallos\n- sistemas-distribuidos\n- aws\n- slack\n- resiliencia\n- alta-disponibilidad\n- arquitectura\n\n[Volver al Blog](<https://lucioduran.com/es/blog>)"}],"links":[{"text":"English","url":"https://lucioduran.com/blog/cell-based-architecture-blast-radius-isolation"},{"text":"AWS","url":"https://aws.amazon.com/"},{"text":"Volver al Blog","url":"https://lucioduran.com/es/blog"}],"structuredData":[{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","@id":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation#article","mainEntityOfPage":{"@type":"WebPage","@id":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation"},"headline":"Arquitectura Basada en Celdas: Aislamiento de Radio de Explosión, Shuffle Sharding y Cómo AWS y Slack Reducen Dominios de Fallo","description":"Un vistazo técnico profundo a la arquitectura basada en celdas, cómo aislar fallos a una fracción de usuarios a través de celdas independientes, shuffle sharding, enrutamiento de celdas y patrones de implementación real extraídos de AWS, Slack y sistemas de producción.","datePublished":"2025-12-06","author":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"publisher":{"@type":"Person","@id":"https://lucioduran.com/#person","name":"Lucio Durán","url":"https://lucioduran.com"},"image":"https://statics.lucioduran.com/images/lucioduran-social-card.jpg","url":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation","inLanguage":"es","isPartOf":{"@id":"https://lucioduran.com/blog#blog"},"articleSection":"Architecture","keywords":"cell-based-architecture, blast-radius, shuffle-sharding, aislamiento-de-fallos, sistemas-distribuidos, aws, slack, resiliencia, alta-disponibilidad, arquitectura","wordCount":832,"timeRequired":"PT5M","workTranslation":[{"@type":"BlogPosting","inLanguage":"en","url":"https://lucioduran.com/blog/cell-based-architecture-blast-radius-isolation"}]},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https://lucioduran.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://lucioduran.com/es/blog"},{"@type":"ListItem","position":3,"name":"Arquitectura Basada en Celdas: Aislamiento de Radio de Explosión, Shuffle Sharding y Cómo AWS y Slack Reducen Dominios de Fallo","item":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation"}]},{"@type":"FAQPage","mainEntity":[{"@type":"Question","name":"¿Cómo difiere la arquitectura basada en celdas de los microservicios?","acceptedAnswer":{"@type":"Answer","text":"Los microservicios dividen por función, un servicio para auth, otro para pagos. La arquitectura basada en celdas divide por tenant. Cada celda corre TODOS los servicios para un SUBCONJUNTO de tenants. La diferencia clave es el boundary de fallo: un fallo de microservicio afecta a todos los usuarios de esa función, mientras un fallo de celda afecta solo a usuarios asignados a esa celda."}},{"@type":"Question","name":"¿Qué es shuffle sharding y por qué importa?","acceptedAnswer":{"@type":"Answer","text":"Shuffle sharding asigna cada tenant a un subconjunto random de celdas (típicamente 2 de N). Si la celda A falla, solo los tenants cuyo shard set incluye la celda A son afectados, y ese es tenants hacen failover a su segunda celda. Con 8 celdas y shards de 2 celdas, cualquier fallo de una celda afecta solo al 25% de tenants, y la mayoría se recupera automáticamente."}},{"@type":"Question","name":"¿Cuándo la arquitectura basada en celdas es overkill?","acceptedAnswer":{"@type":"Answer","text":"Si tu sistema tiene menos de 1000 tenants, sirve menos de 10K requests/segundo, o tiene un equipo menor a 5 ingenieros. El overhead operacional de mantener múltiples stacks de infraestructura independientes es significativo. Considerá aislamiento de fallos más simple primero, multi-región active-active, o simplemente circuit breaking exhaustivo."}}]}]}],"contentHash":"7e10a2bbc96ec863a3ece70756a9001e0fa76b9d2e861da51f1eb068b6105765","provenance":{"method":"Deterministic serialization of the server-rendered main element","source":"https://lucioduran.com/es/blog/cell-based-architecture-blast-radius-isolation","hashAlgorithm":"sha256","hashScope":"JSON document fields before contentHash and provenance","sourceHTMLBytes":59279,"contentBytes":9827}}