La lliçó anterior va deixar fora d'HDFS, deliberadament, les fotos dels productes: milers de fitxers petits que la web ha de servir per HTTP, amb metadades, versions i una durabilitat que no depengui d'un NameNode. L'emmagatzematge d'objectes va néixer exactament per a això. Renuncia als directoris, a les escriptures parcials i al rename, i a canvi ofereix un model pla de buckets i claus, una API HTTP que Amazon S3 va convertir en estàndard de facto, durabilitat d'"onze nous" mitjançant replicació i codificació d'esborrament, i un cost per gigabyte que cap disc de xarxa no iguala. Avui és el magatzem per defecte de fotos, vídeos, còpies de seguretat, documents i, cada cop més, del mateix llac de dades. En aquesta lliçó entendrem el seu model i la seva API, veurem com s'aconsegueix la durabilitat (amb un exemple numèric de Reed-Solomon), aprendrem a reconèixer quan no és l'eina adequada, i el posarem a funcionar a Quilòmetre Zero amb MinIO a docker-compose.yml i un mòdul boto3 amb què la Formatgeria Montblanc pujarà la foto del seu formatge-curat i la web la mostrarà mitjançant URLs presignades.

1. Objecte, fitxer i bloc
2. El model d'objectes: buckets, claus, metadades i versions
3. L'API S3 com a estàndard de facto
4. Durabilitat: replicació i codificació d'esborrament (Reed-Solomon)
5. Consistència als magatzems d'objectes
6. Quan fer servir objectes i quan no
7. Cost: emmagatzematge, operacions i egress
8. Objectes a Quilòmetre Zero: fotos, factures i backups
9. Pràctica: MinIO, mc i serveis/cataleg/fotos.py amb boto3
10. Errors Comuns i Consells
11. Exercicis
12. Conclusió

Hi ha tres maneres de presentar l'emmagatzematge a un programa, i convé distingir-les abans de res:

La columna de "modificació" és la que ho canvia tot: un objecte és immutable. Per canviar un byte es puja un objecte nou amb la mateixa clau. Aquesta immutabilitat simplifica la replicació (dues còpies d'un objecte són idèntiques o una d'elles és d'una altra versió, no hi ha estats intermedis) i és la raó que els magatzems d'objectes escalin tant i costin tan poc. També és la raó de gairebé totes les seves limitacions (apartat 6).

• Bucket: contenidor de nivell superior, amb nom únic (a S3, únic a nivell global; a MinIO, per desplegament). Un bucket té regió, política d'accés, configuració de versionat i regles de cicle de vida. Quilòmetre Zero farà servir km0-fotos, km0-factures i km0-backups.
• Clau (key): el nom de l'objecte dins del bucket, una cadena de fins a 1024 bytes. No hi ha directoris: fotos/formatge-curat/original.jpg és una única cadena, i la barra no significa res per al sistema. Les consoles i eines mostren "carpetes" agrupant per prefix, però és una il·lusió: llistar "la carpeta fotos/formatge-curat/" és una operació LIST amb prefix=fotos/formatge-curat/.
• Dades: de 0 bytes a 5 TB (S3). Opaques: el sistema no interpreta el contingut.
• Metadades: del sistema (Content-Type, Content-Length, Last-Modified, ETag) i de l'usuari (x-amz-meta-productor: formatgeria-montblanc, fins a 2 KB en total). Les metadades viatgen amb l'objecte i es recuperen amb HEAD sense descarregar les dades. No es poden modificar sense reescriure l'objecte (es fa amb una còpia sobre si mateix).
• Versionat: si el bucket l'activa, cada PUT sobre una clau existent no la sobreescriu sinó que crea una nova versió amb el seu VersionId, i DELETE no esborra sinó que hi col·loca un marcador d'esborrament a sobre. Les versions anteriors continuen allà i es poden recuperar: és la protecció més senzilla contra l'esborrat accidental i contra un procés que puja fitxers corruptes.
• Cicle de vida (lifecycle): regles declaratives per prefix o etiqueta: "els objectes amb l'etiqueta tipus=miniatura i més de 90 dies passen a classe d'emmagatzematge freda", "les versions no actuals s'esborren als 30 dies", "les pujades multipart incompletes s'avorten als 7 dies". El sistema les aplica sol, sense codi.
• Classes d'emmagatzematge: el mateix objecte pot viure en nivells amb cost i temps d'accés diferents: estàndard (mil·lisegons), accés infreqüent (més barat per GB, més car per lectura), arxiu (S3 Glacier: hores per recuperar, cèntims per TB). MinIO implementa tiering cap a un altre magatzem remot.
• Etiquetes (tags): parells clau-valor per classificar objectes (campanya=setmana-del-formatge-artesa) i dirigir les regles de cicle de vida i les polítiques d'accés.

Amazon va llançar S3 el 2006 amb una API REST senzilla, i avui pràcticament tots els magatzems d'objectes la implementen: MinIO, Ceph RGW, Google Cloud Storage (mode interoperable), Backblaze B2, Cloudflare R2, Wasabi… Aprendre S3 és aprendre'ls tots. Les operacions bàsiques:

Dos conceptes que mereixen detall:

ETag. Cada objecte té una etiqueta d'entitat que canvia si canvia el contingut. Per a pujades simples és l'MD5 del contingut ("9e107d9d372bb6826bd81d3542a419d6"), cosa que permet verificar la integritat d'una pujada comparant l'MD5 local amb l'ETag retornat. Per a pujades multipart és l'MD5 dels MD5 de les parts seguit de -N (nombre de parts), així que no serveix com a suma del fitxer sencer. Es fa servir també en lectures condicionals: la web demana GET amb If-None-Match: "<etag>" i rep 304 Not Modified si la foto no ha canviat.

URLs presignades. El magatzem d'objectes no hauria de ser accessible públicament, i la web de Quilòmetre Zero no vol fer de proxy de cada foto (pagaria l'amplada de banda dues vegades i afegiria latència). La solució és que el servei cataleg, que sí que té credencials, signi un URL de descàrrega amb una caducitat (per exemple 15 minuts) i el doni al navegador; el navegador descarrega directament del magatzem, que verifica la signatura i la data. El mateix mecanisme funciona per a pujades: la Formatgeria Montblanc rep un URL presignat de PUT i puja la seva foto directament al bucket sense passar per cataleg. La signatura (Signature V4) és un HMAC-SHA256 de la petició canònica amb la clau secreta; el servidor la recalcula i compara. És un exemple perfecte de capacitat (capability): un permís portàtil i limitat, sense comptes ni sessions, tema que reapareixerà a 06-01.

S3 anuncia una durabilitat del 99,999999999 % anual ("onze nous"): si desees 10 milions d'objectes, l'expectativa és perdre'n un cada 10 000 anys. No és una xifra de disponibilitat (aquesta és del 99,9 %–99,99 %); és la probabilitat que els bytes continuïn existint. S'aconsegueix amb dues tècniques.

Replicació. N còpies completes en N dominis de fallada diferents (discos, servidors, racks, centres de dades). Amb 3 còpies es tolera la pèrdua de 2 i el sobrecost és del 200 % (3 bytes desats per cada byte útil). És el que fa HDFS (04-02) i és simple i ràpida de llegir (qualsevol còpia serveix).

Codificació d'esborrament (erasure coding). En lloc de copiar, es divideix l'objecte en k fragments de dades i es calculen m fragments de paritat, de manera que qualssevol k dels k+m fragments són suficients per reconstruir l'objecte. Es toleren m pèrdues amb un sobrecost de només m/k. L'algorisme habitual és Reed-Solomon, la mateixa família de codis que fan servir els CD, els QR i les comunicacions espacials.

La intuïció, sense àlgebra de cossos finits: pensa en k = 2 dades, d1 i d2, i m = 2 paritats:

Desem [d1, d2, p1, p2] en quatre discos. Si perdem d1 i d2 (els dos de dades), tenim dues equacions i dues incògnites: d2 = p2 − p1, d1 = p1 − d2. Si perdem d1 i p2: d1 = p1 − d2. Qualsevol parella de supervivents és suficient. Reed-Solomon generalitza això a qualsevol k i m amb coeficients triats perquè tot subconjunt de k fragments sigui resoluble, operant en un cos finit (GF(2⁸)) perquè les sumes i multiplicacions es facin sobre bytes sense desbordar. Un exemple numèric amb enters per veure que funciona:

Comparem configuracions reals per a 1 TB de dades útils:

El preu de la codificació d'esborrament és la reconstrucció: per llegir un objecte cal reunir k fragments de k nodes (més latència que llegir una còpia), i per reparar un disc perdut cal llegir k fragments de cada objecte afectat (molt trànsit de xarxa). Per això els sistemes la fan servir per a dades grans i fredes, i mantenen replicació (o memòries cau, 04-05) per al petit i calent; molts fan totes dues coses: replicació per a objectes petits i erasure coding a partir d'una certa mida.

Els onze nous es calculen combinant la probabilitat de fallada anual d'un disc (1–3 %), el temps de reconstrucció després d'una fallada (hores) i el nombre de fallades simultànies que calen per perdre dades (m+1 al mateix grup dins d'aquesta finestra). Amb RS(8,4) i reparació en hores, aquesta coincidència és astronòmicament improbable. A això s'hi sumen les sumes de comprovació per fragment i l'scrubbing: un procés de fons rellegeix tot periòdicament per detectar corrupció silenciosa (bit rot) i reparar-la abans que s'acumulin fallades.

Durant 14 anys, S3 va ser eventualment consistent per a sobreescriptures i esborrats: després d'un PUT sobre una clau existent, un GET podia retornar la versió anterior durant uns segons; després d'un DELETE, un LIST podia continuar mostrant la clau. El desembre de 2020 Amazon va anunciar consistència forta read-after-write per a totes les operacions: qualsevol GET, HEAD o LIST posterior a un PUT o DELETE confirmat veu el nou estat. En el vocabulari de 03-01, cada objecte és linealitzable, i en el de 03-02, S3 és CP (una escriptura no es confirma fins que el quòrum de rèpliques la té). MinIO ofereix la mateixa garantia dins d'un desplegament, i Ceph RGW també.

No tots els proveïdors ho fan: alguns magatzems compatibles amb S3 i les configuracions de replicació entre regions són eventuals (la còpia a l'altra regió triga segons o minuts). I hi ha un matís important fins i tot amb consistència forta: no hi ha transaccions entre objectes. Pujar original.jpg i després miniatura-300.jpg són dues operacions independents; un lector pot veure la primera i no la segona. Si l'aplicació necessita que apareguin juntes, puja primer les miniatures i al final l'objecte "índex" que les referencia, o desa la referència a la base de dades només quan totes les pujades han acabat.

Finalment, les memòries cau davant del magatzem (una CDN, tema de 08-04, o un navegador amb Cache-Control) reintrodueixen la consistència eventual pel seu compte: reemplaçar original.jpg no buida la CDN. Per això la pràctica comuna és no sobreescriure claus de contingut: es puja original-v3.jpg (o es fa servir un hash del contingut com a part de la clau) i s'actualitza la referència. La immutabilitat de l'objecte s'estén així a la clau.

Un magatzem d'objectes encaixa quan les dades són:

• Immutables o de substitució completa: fotos, vídeos, PDF, backups, fitxers d'esdeveniments tancats, artefactes de compilació, models entrenats.
• Grans en volum total, amb accés per clau coneguda o per prefix.
• Servides per HTTP a navegadors, apps o a altres serveis, sovint amb CDN al davant.
• Tolerants a desenes de mil·lisegons per operació.

I no encaixa quan cal:

• Semàntica de fitxers: seek i escriptura parcial, append, bloqueigs, directoris reals. Els sistemes que munten S3 com a disc (s3fs, Mountpoint) funcionen per a lectures, però cada escriptura reescriu l'objecte sencer.
• Reanomenament atòmic. mv fotos/tmp/x.jpg fotos/formatge-curat/original.jpg en un sistema de fitxers és una operació atòmica de metadades; a S3 és CopyObject + DeleteObject, dues operacions, sense atomicitat i amb cost proporcional a la mida. Moure un "directori" d'un milió d'objectes és un milió de còpies. Molts motors de processament (Mòdul 5) van tenir problemes per això en passar d'HDFS a S3, i per això existeixen formats de taula (Iceberg, Delta) que eviten reanomenar.
• Latència baixa i moltes operacions petites: llegir 10 000 objectes d'1 KB són 10 000 peticions HTTP; una base de dades (04-04) o una memòria cau (04-05) ho fa mil vegades més ràpid.
• Llistats freqüents i grans: LIST està paginat a 1000 i és l'operació més lenta; l'aplicació ha de desar a la seva base de dades quins objectes existeixen, no descobrir-los llistant.
• Dades que canvien sovint: cada canvi és una versió nova de l'objecte complet.

Els magatzems d'objectes al núvol cobren per tres conceptes, i el tercer sorprèn molts equips:

L'egress és la raó principal de posar una CDN al davant (08-04): la CDN guarda les fotos a la memòria cau de les seves vores i el bucket només paga el primer enviament a cada vora. També és la raó que moure dades entre núvols sigui car i que el llac de dades (04-02) i el còmput (Mòdul 5) hagin de ser a la mateixa regió. Alguns proveïdors (R2, B2) no cobren egress, i un MinIO propi canvia el model: no hi ha cost per GB servit, però hi ha discos, servidors i personal que els operi.

Tres tipus de dades de la plataforma van al magatzem d'objectes:

Les fotos són el cas principal. El flux complet, des que la Formatgeria Montblanc tria una foto al seu panell fins que l'Anna la veu a la web:

cataleg mai no toca els bytes de la foto: signa, valida i desa referències. És el patró habitual i el que permet que el magatzem, no el servei, absorbeixi l'amplada de banda.

MinIO és un magatzem d'objectes de codi obert compatible amb S3, escrit en Go, que es desplega en un sol binari. En producció s'executa en mode distribuït (diversos nodes, diversos discos per node, codificació d'esborrament automàtica); per a km0/ n'hi ha prou amb un node amb un volum. Afegim al docker-compose.yml:

mc (MinIO Client) és la CLI, que funciona amb qualsevol S3. Les ordres útils des de la teva màquina:

boto3 és l'SDK oficial d'AWS per a Python i, gràcies a la compatibilitat de MinIO, funciona amb només canviar endpoint_url. El mòdul serveis/cataleg/fotos.py concentra tot el que cataleg necessita:

Comentaris sobre les parts menys evidents:

• Config(signature_version="s3v4", s3={"addressing_style": "path"}): MinIO local no té DNS amb comodins, així que el bucket va al path (/km0-fotos/…) i no al host (km0-fotos.localhost). Signature V4 és la que fan servir els URLs presignats moderns.
• pujar_foto comprova l'ETag contra l'MD5 local: si la xarxa ha corromput alguna cosa, es detecta a l'instant. Amb put_object (pujada simple) aquesta igualtat es compleix; amb multipart no, com hem vist a l'apartat 3. Per a fotos de més de 100 MB, fes servir s3.upload_file, que fa multipart automàticament amb reintents per part.
• CacheControl: immutable: com que hem promès no sobreescriure contingut que la CDN hagi de guardar en memòria cau, podem deixar-la guardar un any. Quan la formatgeria canviï la foto, la nova versió tindrà un altre VersionId i, a la pràctica de Quilòmetre Zero, la web referenciarà original.jpg?v=<etag> perquè l'URL canviï.
• url_descarrega no parla amb el servidor: generate_presigned_url calcula la signatura localment amb la clau secreta. És instantani i no consumeix cap operació del bucket. Fixa't que l'ExpiresIn no pot superar 7 dies amb Signature V4.
• url_pujada inclou ContentType i Metadata als paràmetres signats: el productor **ha d'**enviar exactament aquestes capçaleres, o la signatura no quadra. És la manera de forçar que la pujada porti les metadades que cataleg ha decidit.
• restaurar_versio mostra el truc de "modificar" un objecte immutable: copiar-lo sobre si mateix des de la versió desitjada, cosa que crea una versió nova amb el contingut antic.
• configurar_cicle_vida: StorageClass a MinIO es refereix a un nivell de tiering definit amb mc ilm tier add (per exemple, un altre MinIO amb discos lents o un S3 Glacier); a S3 es faria servir STANDARD_IA o GLACIER. La regla de multipart abandonades evita pagar per parts òrfenes que ningú no veu als llistats.

Prova ràpida en dues línies:

El curl -I retorna 200 OK amb Content-Type: image/jpeg, ETag, x-amz-meta-productor: formatgeria-montblanc i Cache-Control. Espera 15 minuts i repeteix: 403 Forbidden amb Request has expired. Això és l'URL presignat funcionant.

• Pensar en carpetes. No existeixen. LIST per prefix és lent i paginat; desa a la base de dades quines claus té cada producte en lloc de llistar el bucket a cada pàgina vista.
• Sobreescriure claus que una CDN o un navegador guarden en memòria cau. El bucket serà consistent; les memòries cau no. Canvia la clau (hash o versió al nom) i actualitza la referència.
• Exposar credencials al navegador o al productor. Mai. Signa URLs des del servei, amb caducitat curta i els paràmetres que vols forçar inclosos a la signatura.
• Buckets públics "perquè funcioni". Un bucket públic amb LIST habilitat és la fuita de dades més comuna del núvol. mc anonymous set none i URLs presignats o CDN amb signatura.
• Fer servir rename o moure prefixos grans. No hi ha reanomenament: és còpia + esborrat per objecte. Dissenya les claus per no haver de moure-les.
• Confiar en l'ETag com a MD5 de pujades multipart. No ho és. Si necessites un hash del fitxer complet, calcula'l i desa'l com a metadada (x-amz-meta-sha256) o fes servir les sumes de comprovació d'objectes complets (ChecksumAlgorithm).
• Oblidar l'egress i les operacions al pressupost. Servir fotos directament des del bucket a milers d'usuaris costa més que emmagatzemar-les; la CDN (08-04) és una decisió econòmica abans que de latència.
• Sense versionat ni cicle de vida. El versionat és una assegurança barata contra esborrats accidentals; el cicle de vida evita que les versions i les multipart abandonades creixin sense límit. Activa'ls el primer dia.

Exercici 1. Quilòmetre Zero té 4 200 productes amb 3 variants de foto (original 1,8 MB, miniatura-800 180 KB, miniatura-300 35 KB) i 2 000 productors. Durant la Setmana del Formatge Artesà la web serveix 6 milions de vistes de producte al dia, cadascuna amb una miniatura-800. (a) Calcula l'emmagatzematge total al bucket i el seu cost mensual a 0,02 €/GB. (b) Calcula l'egress diari i mensual a 0,08 €/GB si se serveix directament des del bucket. (c) Quin percentatge del trànsit caldria servir des d'una CDN perquè l'egress del bucket baixi al 5 % del càlcul anterior, i quin canvi a les claus ho fa possible sense risc de servir fotos obsoletes?

Exercici 2. Implementa generar_miniatures(slug) a fotos.py: descarrega original.jpg en memòria amb get_object, genera les variants de 800 i 300 px amb Pillow i puja-les amb pujar_foto reutilitzant les metadades de l'original (llegeix-les amb head_object). Després descriu què pot veure la web si un usuari carrega la pàgina de formatge-curat just entre la pujada de l'original i la de les miniatures, i com evitaries mostrar una imatge trencada.

Exercici 3. Amb RS(k=4, m=2) sobre 6 discos, un objecte de 24 MB es divideix en 4 fragments de dades de 6 MB i 2 de paritat. (a) Quants bytes ocupa en total i quin és el sobrecost enfront de 3 rèpliques? (b) Si fallen dos discos, quants MB cal llegir per reconstruir l'objecte en una lectura, i quants per reparar un sol fragment perdut d'aquest objecte? (c) Explica per què MinIO, amb 6 discos, fa servir per defecte RS(3,3) (paritat = meitat) en lloc de RS(4,2) i què es guanya i què es perd.

Solució 1:

(a) Per producte: 1,8 MB + 0,18 MB + 0,035 MB ≈ 2,0 MB. Total: 4 200 × 2,0 MB ≈ 8,5 GB (més versions no actuals durant 30 dies; suposem un 20 % extra: ~10 GB). Cost: 10 GB × 0,02 € ≈ 0,20 €/mes. L'emmagatzematge és irrellevant.

(b) Egress diari: 6 000 000 × 180 KB ≈ 1,08 TB/dia; mensual ≈ 32 TB. A 0,08 €/GB: ≈ 86 €/dia, 2 600 €/mes. Tretze mil vegades el cost d'emmagatzemar. Les operacions GET (6 M/dia × 0,4 €/M ≈ 2,4 €/dia) també superen l'emmagatzematge.

(c) Perquè el bucket serveixi només el 5 %, la CDN ha d'atendre el 95 % de les peticions des de la memòria cau (hit ratio ≥ 95 %), cosa que és realista amb 4 200 objectes petits i Cache-Control: max-age=31536000, immutable. La condició perquè aquest max-age d'un any sigui segur és que la clau (o l'URL) canviï quan canviï el contingut: fotos/formatge-curat/miniatura-800.jpg?v=<etag> o fotos/formatge-curat/<etag>/miniatura-800.jpg. Amb claus immutables no cal invalidar la CDN mai; es detallarà a 08-04.

Solució 2:

(Es reutilitza pujar_foto, que ja fixa variant a les metadades.) Entre la pujada de l'original i la de les miniatures, el bucket conté original.jpg però no miniatura-800.jpg: la web, que demana un URL presignat de la miniatura, obtindria un URL vàlid però el GET retornaria 404 NoSuchKey i el navegador mostraria la imatge trencada. El magatzem és consistent per objecte, però no hi ha transacció entre objectes (apartat 5). Solució: cataleg no marca la foto com a "disponible" a km0_cataleg (ni publica foto.pujada per a la web) fins que el generador confirma les miniatures; mentrestant la web mostra la foto anterior o una imatge de farciment. Alternativa més robusta: el generador puja les miniatures abans que s'actualitzi la referència, i la referència (a la base de dades) és l'únic "commit" visible.

Solució 3:

(a) 4 × 6 MB + 2 × 6 MB = 36 MB per a 24 MB útils: sobrecost del 50 %. Amb 3 rèpliques serien 72 MB (200 %): la codificació d'esborrament estalvia la meitat del disc tolerant les mateixes 2 pèrdues.

(b) Per llegir l'objecte calen 4 fragments qualssevol: 24 MB llegits de 4 discos (amb les dues fallades, exactament els 4 supervivents). Per reparar un sol fragment perdut de 6 MB cal llegir 4 fragments (24 MB) i recalcular: el cost de reparació és k vegades la mida del fragment, que és la penalització característica de l'erasure coding enfront de la rèplica (on reparar 6 MB costa llegir 6 MB).

(c) Amb RS(3,3), cada objecte tolera la pèrdua de 3 discos de 6 (la meitat), amb sobrecost del 100 %; amb RS(4,2) en tolera 2, amb sobrecost del 50 %. MinIO tria per defecte la configuració més segura (i amb 6 discos, dues fallades simultànies no són tan rares durant una finestra de reparació llarga), i deixa que l'operador abaixi la paritat (MINIO_STORAGE_CLASS_STANDARD=EC:2) quan prefereix capacitat. Es guanya tolerància a fallades i lectures que necessiten només 3 fragments; es perd el 50 % addicional de disc.

L'emmagatzematge d'objectes canvia el contracte de l'emmagatzematge: buckets i claus planes en lloc de directoris, objectes immutables que es reemplacen sencers, metadades que viatgen amb les dades, versionat i regles de cicle de vida que el sistema aplica sol. L'API S3 (PUT/GET/HEAD/LIST, multipart, ETag, URLs presignats) és l'estàndard que MinIO, Ceph i la resta implementen. La durabilitat d'onze nous s'aconsegueix combinant replicació amb codificació d'esborrament, on Reed-Solomon reconstrueix un objecte a partir de qualssevol k dels seus k+m fragments amb un sobrecost del 33–50 % en lloc del 200 % de tres còpies, a canvi de lectures i reparacions més costoses. S3 i MinIO són avui fortament consistents per objecte, però no hi ha transaccions entre objectes ni reanomenament atòmic, i les memòries cau davant del bucket retornen la consistència eventual, per la qual cosa la bona pràctica és no sobreescriure claus. L'egress, no l'emmagatzematge, domina la factura, i aquesta és la raó econòmica de la CDN que veurem a 08-04. Quilòmetre Zero ha destinat a objectes les seves fotos (km0-fotos, amb fotos.py, pujada directa de la Formatgeria Montblanc per URL presignat i servei a la web amb URLs de 15 minuts), les seves factures i els seus backups, i ho ha muntat amb MinIO i mc a docker-compose.yml.

Ja tenim on desar fitxers massius (HDFS) i fitxers que se serveixen (objectes). Falta l'emmagatzematge que mou la plataforma cada segon: registres petits, consultats i actualitzats amb baixa latència, amb transaccions i amb les garanties de consistència que vam triar a 03-02. Aquest és el terreny de les bases de dades distribuïdes, on comandes migrarà a Cassandra, inventari es quedarà a PostgreSQL, i l'anell de hashing consistent de 04-01 reapareixerà amb rèpliques i nivells de consistència per operació.