El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

Queda l'última de les quatre càrregues que vam diagnosticar a 06-01, i és la més absurda de totes. El catàleg de MercadoFresco rep 4.100 consultes per minut en hora punta i, segons les traces d'X-Ray de 05-02, el 94 % retornen exactament el mateix resultat que l'anterior. Els preus i les descripcions canvien un cop al dia, a les 06:00, quan arriba la càrrega de la llotja.

Aurora resol cadascuna d'aquestes consultes correctament en uns 6 mil·lisegons. El problema no és que sigui lenta: és que fer-ho 4.100 vegades per minut per no aportar cap informació nova és feina malgastada, i aquest malbaratament es paga tres vegades —en latència per al client, en capacitat d'Aurora que cal pagar encara que no produeixi res, i en risc, perquè aquesta càrrega constant deixa el clúster sense marge just quan arriba el pic del divendres—.

Amazon ElastiCache és el servei gestionat de memòria cau en memòria d'AWS, compatible amb Redis (i la seva bifurcació de codi obert Valkey) i amb Memcached. Aquí el catàleg se serveix des de memòria en microsegons, les sessions deixen de necessitar sessions enganxoses a l'ALB —el cap per lligar que 03-03 va deixar pendent— i el mòdul es tanca amb la capa de dades de MercadoFresco completa.

Avís de cost. Un node d'ElastiCache es paga per hora, hi hagi trànsit o no, igual que una instància EC2. Un cache.r7g.large oblidat costa uns 130 USD al mes. Esborra els grups de rèplica que creïs per practicar. Totes les dades són fictícies.

Contingut

Per què desar a la memòria cau, i què no s'hi ha de desar
Redis davant de Memcached
Arquitectura: nodes, grups de rèplica i mode clúster
Particionament, ranures hash, commutació per error i punts d'enllaç
Patrons de memòria cau: cache-aside, write-through, write-behind i read-through
El catàleg de MercadoFresco amb cache-aside
TTL, invalidació i coherència
Estampida de memòria cau i claus calentes
Estructures de Redis aplicades a la botiga
Comptadors atòmics i el límit de l'estoc
Sessions a Redis: adéu a les sessions enganxoses
Seguretat: xarxa, xifratge i control d'accés
Mètriques, alarmes i el mesurament de l'abans i el després
MemoryDB i DAX: quan no és ElastiCache
Costos i estalvi mesurat
Errors habituals i consells
Exercicis
La capa de dades completa de MercadoFresco
Conclusió

Per què desar a la memòria cau, i què no s'hi ha de desar

Una memòria cau guarda el resultat d'una operació cara per no haver de repetir-la. Aporta tres coses diferents i convé separar-les:

Benefici	Abans	Després
Latència	6 ms per consulta a Aurora	0,3 ms des de memòria
Cost per consulta	Capacitat d'Aurora (ACU)	Node fix, cost marginal gairebé nul
Protecció	Tot el trànsit arriba a la base de dades	La base només veu les fallades de memòria cau

El tercer és el que més se subestima. Una memòria cau amb un 95 % d'encerts converteix 4.100 consultes per minut en 205: la base de dades deixa d'estar al límit i recupera el marge que necessita per al pic.

Què s'ha de desar a la memòria cau, per ordre de rendibilitat: dades que es llegeixen molt més del que s'escriuen (el catàleg, 4.100:1), resultats de càlculs cars, dades que toleren estar lleugerament desactualitzades i objectes que es reconstrueixen a partir de diverses fonts. Què no s'hi ha de desar: dades que canvien a cada lectura, dades l'exactitud momentània de les quals és crítica —l'estoc en cobrar—, dades que només es llegeixen un cop (una cerca amb filtres molt específics que ningú no repetirà) i dades personals sensibles sense una raó clara, perquè una memòria cau és una còpia més que cal protegir i esborrar sota el RGPD.

Redis davant de Memcached

	Redis / Valkey	Memcached
Estructures de dades	Cadenes, hashes, llistes, conjunts, conjunts ordenats, fluxos	Només cadenes
Persistència	Sí (instantànies i AOF)	No
Rèpliques	Sí, amb commutació automàtica	No
Alta disponibilitat	Multi-AZ amb commutació	Cap
Particionament	Natiu, amb mode clúster	Al client
Operacions atòmiques	Moltes (`INCR`, `ZADD`, transaccions, scripts Lua)	Poques
Publicació i subscripció	Sí	No
Model de fils	Un fil per nucli lògic (majoritàriament monofil)	Multifil
Casos ideals	Gairebé tots	Memòria cau pura, objectes grans, multifil

L'elecció per a MercadoFresco és Redis, per tres raons concretes i no per popularitat. Necessitem estructures i no només cadenes: conjunts ordenats per al rànquing del divendres, hashes per a la cistella ràpida, comptadors atòmics. Necessitem alta disponibilitat: si la memòria cau de sessions cau, tots els clients perden la sessió alhora, i amb Memcached no hi ha rèplica possible. I necessitem operacions atòmiques per als comptadors, que a Memcached són limitades.

Memcached continua tenint el seu nínxol —memòria cau purament volàtil, molt simple, amb objectes grans i on el multifil aporta més rendiment per node—, però no és aquest cas. Sobre Valkey: és la bifurcació de codi obert de Redis després del seu canvi de llicència, compatible a escala de protocol, amb suport d'ElastiCache i a un preu més baix. Per a un desplegament nou és l'opció per defecte raonable, i el que s'explica aquí s'hi aplica igual.

Arquitectura: nodes, grups de rèplica i mode clúster

Un node és la unitat mínima: una instància amb memòria i un procés de Redis. Un fragment (shard) és un node primari més de 0 a 5 rèpliques amb les mateixes dades. I un grup de rèplica és el conjunt de fragments que formen el desplegament. D'aquí les dues topologies possibles:

graph TD
    subgraph MCD["Mode cluster DESACTIVAT · 1 fragment"]
        P1["Primari<br/>tot el conjunt de dades"] --> R1["Replica AZ b"]
        P1 --> R2["Replica AZ a"]
    end
    subgraph MCA["Mode cluster ACTIVAT · 3 fragments"]
        F1["Fragment 1<br/>ranures 0-5460"] --> FR1["Replica"]
        F2["Fragment 2<br/>ranures 5461-10922"] --> FR2["Replica"]
        F3["Fragment 3<br/>ranures 10923-16383"] --> FR3["Replica"]
    end

	Mode clúster desactivat	Mode clúster activat
Fragments	1	Fins a 500
Límit de dades	La memòria d'un node	La suma de tots els fragments
Escalat	Vertical (node més gran)	Horitzontal (més fragments)
Client	Qualsevol	Ha d'admetre el protocol de clúster
Operacions multiclau	Sense restricció	Només dins del mateix fragment

MercadoFresco comença amb el mode clúster desactivat. El catàleg són 1,2 GB i les sessions no arriben a 2 GB: tot cap folgadament en un node cache.t4g.medium de 3,09 GiB, amb una rèplica a l'altra AZ. Activar el mode clúster hi afegiria complexitat —restriccions en operacions multiclau, client compatible— sense resoldre cap problema que avui existeixi. És exactament el criteri de 06-01: no afegeixis complexitat que no puguis justificar amb un mesurament.

Particionament, ranures hash, commutació per error i punts d'enllaç

Amb el mode clúster activat, Redis divideix l'espai de claus en 16.384 ranures hash. Cada clau s'assigna a una ranura calculant CRC16(clau) mod 16384, i cada fragment posseeix un rang de ranures. Afegir un fragment redistribueix ranures sense aturar el servei.

Les etiquetes hash forcen que diverses claus caiguin a la mateixa ranura posant entre claus la part que es fa servir per al càlcul: carrito:{4471}:lineas i carrito:{4471}:total van juntes perquè totes dues fan hash només de 4471. És el que permet operar sobre diverses claus relacionades en un clúster particionat.

Multi-AZ amb commutació automàtica promou una rèplica si el primari falla, en 15-60 segons i actualitzant només el punt d'enllaç principal. Cal configurar-ho explícitament i tenir clar què implica: si la persistència no està activada, el que hi hagués només al primari es perd. Per a una memòria cau és acceptable —es repobla des d'Aurora—; per a sessions no ho és tant, i per això MercadoFresco activa rèpliques i persistència al grup de sessions.

Els punts d'enllaç disponibles són quatre:

Punt d'enllaç	Quan existeix	Ús
Principal	Mode clúster desactivat	Escriptures i lectures que exigeixen l'última dada
De lectura	Mode clúster desactivat	Reparteix lectures entre rèpliques
De configuració	Mode clúster activat	L'únic que fa servir l'aplicació; el client descobreix la topologia
De node	Sempre	Diagnòstic; mai a l'aplicació

Igual que amb Aurora, fer servir el punt d'enllaç de node a l'aplicació és l'error que es paga a la primera commutació per error.

Patrons de memòria cau: cache-aside, write-through, write-behind i read-through

Patró	Qui escriu a la memòria cau	Avantatge	Inconvenient
Cache-aside (càrrega diferida)	L'aplicació, després d'una fallada de lectura	Només es desa el que es fa servir; resistent a fallades de memòria cau	Primer accés lent; hi pot haver dades obsoletes
Write-through	L'aplicació, en escriure	La memòria cau sempre està al dia	Es desa tot, es faci servir o no; encareix l'escriptura
Write-behind	La memòria cau, de manera diferida	Escriptures molt ràpides	Risc de pèrdua de dades; complex
Read-through	La mateixa memòria cau, transparent	Codi d'aplicació net	Requereix una capa que ho implementi

MercadoFresco fa servir cache-aside per al catàleg —el patró per defecte i el més robust: si la memòria cau desapareix, l'aplicació continua funcionant, només que més lenta— combinat amb write-through a la càrrega de la llotja de les 06:00, que actualitza la memòria cau alhora que la base de dades perquè el primer client del matí no la trobi buida. Write-behind es descarta explícitament: escriure primer a memòria i bolcar després a Aurora significa que una fallada del node perd comandes.

El catàleg de MercadoFresco amb cache-aside

import json, hashlib, random
import redis
from redis.exceptions import RedisError

# decode_responses=True retorna str en lloc de bytes: mes comode amb JSON.
# socket_timeout baix es essencial: si la memoria cau no respon, cal anar a la base
# de dades de pressa, no bloquejar la peticio del client.
cache = redis.Redis(
    host="mercadofresco-catalogo.abc123.ng.0001.euw1.cache.amazonaws.com",
    port=6379, ssl=True, decode_responses=True,
    socket_timeout=0.15, socket_connect_timeout=0.15,
    health_check_interval=30,
)

TTL_BASE = 3600  # 1 hora; els preus canvien un cop al dia

def clau_producte(sku: str) -> str:
    # Un prefix amb versio permet invalidar tot el cataleg canviant "v3".
    return f"catalogo:v3:producto:{sku}"

def obtenir_producte(sku: str, connexio_aurora) -> dict:
    clau = clau_producte(sku)

    # 1. Provar la memoria cau. Cap fallada de Redis no ha de trencar la botiga.
    try:
        cru = cache.get(clau)
        if cru is not None:
            return json.loads(cru)            # encert de memoria cau: ~0,3 ms
    except RedisError:
        pass                                   # es registra i es continua

    # 2. Fallada de memoria cau: llegir d'Aurora (la font de veritat).
    with connexio_aurora.cursor() as cur:
        cur.execute("""
            SELECT p.sku, p.nombre, p.descripcion, p.precio, p.categoria,
                   p.origen, p.alergenos, p.unidad_venta
            FROM   productos p
            WHERE  p.sku = %s AND p.activo = true
        """, (sku,))
        fila = cur.fetchone()
    if fila is None:
        return None
    producte = dict(zip(
        ["sku", "nombre", "descripcion", "precio", "categoria",
         "origen", "alergenos", "unidad_venta"], fila))

    # 3. Poblar la memoria cau amb TTL aleatoritzat (mira l'estampida mes avall).
    try:
        ttl = TTL_BASE + random.randint(-300, 300)
        cache.setex(clau, ttl, json.dumps(producte, default=str))
    except RedisError:
        pass

    return producte

Cinc decisions deliberades en aquest codi:

Les fallades de Redis mai no trenquen la petició. Un try/except al voltant de cada operació i un temps d'espera de 150 ms. Una memòria cau caiguda ha de degradar el rendiment, mai la disponibilitat: és l'error més greu que es comet en introduir una memòria cau.
La clau porta versió (catalogo:v3:). Canviar el número invalida tot el catàleg de cop sense recórrer claus, que és el que cal fer quan canvia el format de l'objecte desat.
setex en lloc de set + expire. Una sola operació atòmica; amb dues, una fallada intermèdia deixa una clau sense caducitat, i aquestes claus immortals omplen la memòria cau.
El TTL s'aleatoritza ±5 minuts per evitar que tot caduqui alhora.
Se serialitza a JSON, que és llegible i depurable. Amb volum alt, els formats binaris estalvien memòria i CPU, però convé mesurar-ho abans de complicar-ho.

TTL, invalidació i coherència

Tota memòria cau té el mateix problema de fons: la dada desada pot diferir de la real. Hi ha tres maneres de gestionar-ho i es combinen: la caducitat per TTL (la clau expira sola, incoherència fins al TTL, complexitat mínima), la invalidació explícita (en escriure s'esborra la clau, incoherència gairebé zero) i el write-through (en escriure s'actualitza la clau, incoherència zero). A MercadoFresco la política és explícita i per tipus de dada:

Dada	TTL	Invalidació	Justificació
Fitxa de producte	1 h ± 5 min	Sí, en canviar el preu	Canvia un cop al dia
Llistat de categoria	15 min	No	Canvia poc, tolera desfasament
Estoc aproximat	30 s	No	«Queden poques unitats» tolera desfasament
Rànquing de més venuts	5 min	No	És informatiu
Sessió d'usuari	30 min lliscants	Sí, en tancar la sessió	Seguretat

La invalidació explícita a la càrrega de la llotja:

def actualitzar_preu(sku: str, nou_preu, connexio_aurora):
    # 1. La font de veritat SEMPRE s'escriu primer. Si falla, no es toca la memoria cau.
    with connexio_aurora.cursor() as cur:
        cur.execute("UPDATE productos SET precio = %s WHERE sku = %s",
                    (nou_preu, sku))
    connexio_aurora.commit()

    # 2. Despres s'invalida. S'ESBORRA, no s'actualitza: aixi el lector seguent
    #    recarrega l'objecte complet i no hi ha risc de deixar un objecte a mitges.
    try:
        cache.delete(clau_producte(sku))
    except RedisError:
        pass   # el TTL ho arreglara en menys d'una hora

L'ordre importa: base de dades primer, memòria cau després. A l'inrevés, una fallada entre totes dues operacions deixa la memòria cau amb una dada que la base de dades mai no va arribar a tenir, i aquest error persisteix fins que algú se n'adona. I s'esborra en lloc d'actualitzar perquè una escriptura parcial a la memòria cau és una dada corrupta que se serveix com a bona.

Estampida de memòria cau i claus calentes

L'estampida de memòria cau (thundering herd) passa quan una clau molt consultada caduca i totes les peticions simultànies fallen alhora i van juntes a la base de dades. Amb 4.100 consultes per minut i una clau popular, això són desenes de consultes idèntiques en el mateix instant.

Tres mitigacions, de menys a més complexitat: TTL aleatoritzat, ja aplicat més amunt, que impedeix que moltes claus caduquin en el mateix segon i resol barat la major part del problema; bloqueig de repoblació, amb un sol procés recarregant la clau mentre els altres serveixen el valor antic o esperen breument; i refresc anticipat, que recarrega abans de caducar amb probabilitat creixent a mesura que s'acosta el venciment.

def obtenir_amb_bloqueig(clau: str, carregar, ttl: int = 3600):
    valor = cache.get(clau)
    if valor is not None:
        return json.loads(valor)

    # SET NX EX: nomes un proces aconsegueix el bloqueig. L'EX de 10 s garanteix
    # que el bloqueig s'allibera encara que el proces que l'ha pres mori.
    bloqueig = f"lock:{clau}"
    if cache.set(bloqueig, "1", nx=True, ex=10):
        try:
            dada = carregar()                      # unica consulta a Aurora
            cache.setex(clau, ttl + random.randint(-300, 300),
                        json.dumps(dada, default=str))
            return dada
        finally:
            cache.delete(bloqueig)

    # No hem obtingut el bloqueig: esperar una mica i reintentar la memoria cau.
    time.sleep(0.05)
    valor = cache.get(clau)
    return json.loads(valor) if valor else carregar()

Una clau calenta és l'altre problema: una sola clau que concentra tant trànsit que satura el node que la conté. En mode clúster no es pot repartir, perquè una clau viu en una ranura. Les solucions són replicar la clau amb sufixos (ranking:viernes:0 … :4, triant-ne un a l'atzar en la lectura) o desar-la també a la memòria del procés de l'aplicació amb un TTL de pocs segons. És el mateix concepte que la clau calenta de DynamoDB a 06-02.

Estructures de Redis aplicades a la botiga

Aquí és on Redis es distancia d'una memòria cau genèrica: les estructures permeten resoldre problemes que amb cadenes exigirien llegir, modificar i reescriure l'objecte sencer.

# 1. CADENES · la fitxa de producte serialitzada, amb caducitat.
cache.setex("catalogo:v3:producto:PESC-SALM-001", 3600, json.dumps(producte))

# 2. HASHES · la cistella rapida. Cada camp es un SKU i cada valor, les unitats.
#    Canviar una linia NO exigeix reescriure la cistella sencera: HINCRBY es atomic.
cache.hincrby("carrito:rapido:4471", "PESC-SALM-001", 2)
cache.hincrby("carrito:rapido:4471", "VERD-TOMA-014", -1)
cache.expire("carrito:rapido:4471", 1800)
cistella = cache.hgetall("carrito:rapido:4471")  # {'PESC-SALM-001': '2', ...}

# 3. LLISTES · les ultimes cerques del client, amb topall de 10.
cache.lpush("busquedas:4471", "salmó noruec")
cache.ltrim("busquedas:4471", 0, 9)              # descarta el que sobra
ultimes = cache.lrange("busquedas:4471", 0, 9)

# 4. CONJUNTS ORDENATS · el ranquing de mes venuts del divendres.
#    ZINCRBY suma al marcador de forma atomica; l'ordre es mante sol.
cache.zincrby("ranking:viernes:2026-08-07", 2, "PESC-SALM-001")
top10 = cache.zrevrange("ranking:viernes:2026-08-07", 0, 9, withscores=True)
cache.expire("ranking:viernes:2026-08-07", 604800)   # una setmana

Estructura	Operacions clau	Ús a MercadoFresco	Alternativa a Aurora
Cadena	`SET`, `GET`, `SETEX`	Fitxa de producte	`SELECT` per clau
Hash	`HSET`, `HINCRBY`, `HGETALL`	Cistella ràpida	Taula de línies
Llista	`LPUSH`, `LTRIM`, `LRANGE`	Últimes cerques	Taula amb `LIMIT 10`
Conjunt ordenat	`ZINCRBY`, `ZREVRANGE`	Rànquing del divendres	`GROUP BY` + `ORDER BY`
Comptador	`INCR`, `DECR`, `INCRBY`	Visites, límits de taxa	`UPDATE ... SET n = n + 1`

El conjunt ordenat mereix un comentari: calcular el rànquing de més venuts en SQL exigeix agregar i ordenar totes les línies del dia, mentre que amb ZINCRBY l'ordre es manté incrementalment a cada venda i consultar el top 10 costa temps logarítmic. És la diferència entre un quadre de comandament que s'actualitza cada cinc minuts i un que va en directe.

I un advertiment sobre la cistella ràpida: la cistella autoritativa continua estant a DynamoDB (06-02). El hash de Redis és una còpia calenta per pintar la capçalera. Si el node es reinicia, la cistella no es perd perquè la veritat és en un altre lloc; si es fes servir Redis com a font única, un reinici seria una pèrdua de vendes.

Comptadors atòmics i el límit de l'estoc

INCR i DECR són atòmics: mil processos concurrents produeixen el resultat correcte sense bloquejos. Això els fa ideals per a comptadors de visites, limitació de taxa per IP i estoc aproximat.

# Reservar unitats a la memoria cau ABANS de tocar la base de dades:
# descarta de pressa la majoria d'intents quan ja no queda producte.
restant = cache.decrby("stock:aprox:PESC-SALM-001", unitats)
if restant < 0:
    cache.incrby("stock:aprox:PESC-SALM-001", unitats)     # desfer
    raise SenseEstoc("Producte esgotat")

Advertiment que no admet matisos. Això no és el control d'estoc. És un filtre previ, una optimització que evita que milers de peticions arribin a Aurora quan un producte ja està esgotat. L'estoc real continua sent transaccional a Aurora i es descompta dins de la transacció de confirmació de la comanda, amb `UPDATE stock SET unidades = unidades - :n WHERE sku = :s AND unidades

= :n` comprovant que ha afectat una fila. Si aquesta comprovació falla, la comanda es rebutja encara que la memòria cau digués que hi havia existències.

La raó és la de sempre: una memòria cau pot perdre dades. Un reinici del node, una commutació per error o una expulsió per falta de memòria poden deixar el comptador en un valor incorrecte, i amb producte fresc això significa vendre caixes de maduixes que no existeixen: trucar al client, reemborsar i perdre'l. És exactament la distinció de 06-01: eventual per mostrar, forta per decidir.

Sessions a Redis: adéu a les sessions enganxoses

A 03-03 vam deixar un cap per lligar. L'ALB alb-mercadofresco-tienda té stickiness.enabled=false perquè l'aplicació és sense estat, i vam dir aleshores que «MercadoFresco acabarà fent servir ElastiCache». Aquest és aquell moment.

El problema que resol: si la sessió viu a la memòria de la instància EC2 que va atendre l'usuari, aquest usuari ha de tornar sempre a la mateixa instància. Això obliga a activar sessions enganxoses a l'ALB, i les sessions enganxoses trenquen tres coses: el repartiment de càrrega es desequilibra, en reduir-se l'ASG els usuaris de la instància acabada perden la sessió, i els desplegaments continus expulsen usuaris. Amb les sessions a Redis, qualsevol instància pot atendre qualsevol usuari:

# La sessio viu a Redis; la instancia EC2 no guarda res de l'usuari.
def carregar_sessio(id_sessio: str) -> dict:
    clau = f"sesion:{id_sessio}"
    dades = cache.get(clau)
    if dades is None:
        return {}
    cache.expire(clau, 1800)      # TTL lliscant: es renova amb l'activitat
    return json.loads(dades)

def desar_sessio(id_sessio: str, dades: dict):
    cache.setex(f"sesion:{id_sessio}", 1800, json.dumps(dades))

	Amb sessió local	Amb sessió a Redis
Sessions enganxoses a l'ALB	Necessàries	Innecessàries
Repartiment de càrrega	Desequilibrat	Uniforme
Reduir l'ASG	Expulsa usuaris	Transparent
Desplegament continu	Expulsa usuaris	Transparent
Instància substituïble	No del tot	Sí, completament

Aquest és el tancament del fil que ve de 02-01: l'ASG asg-mercadofresco-tienda pot per fi escalar, reduir-se i reemplaçar instàncies amb total llibertat, perquè cap instància no conté res que pertanyi a un client. Amb dues precaucions: el grup de sessions fa servir rèpliques i persistència, perquè perdre totes les sessions alhora és un incident visible; i les dades de sessió es limiten al imprescindible —identificador de client i preferències—, mai dades de pagament ni informació personal que obligaria a tractar la memòria cau com un magatzem subjecte al RGPD.

Seguretat: xarxa, xifratge i control d'accés

aws elasticache create-replication-group \
  --replication-group-id mercadofresco-catalogo \
  --replication-group-description "Memoria cau de cataleg i sessions" \
  --engine valkey --engine-version 7.2 \
  --cache-node-type cache.t4g.medium \
  --num-cache-clusters 2 \
  --automatic-failover-enabled --multi-az-enabled \
  --cache-subnet-group-name sng-mercadofresco-datos \
  --security-group-ids sg-mercadofresco-cache \
  --at-rest-encryption-enabled \
  --transit-encryption-enabled --transit-encryption-mode required \
  --kms-key-id alias/mercadofresco-datos \
  --snapshot-retention-limit 5 --snapshot-window "03:00-04:00" \
  --tags Key=Proyecto,Value=mercadofresco Key=Entorno,Value=produccion \
         Key=Componente,Value=cache Key=Propietario,Value=luis \
         Key=CentroCoste,Value=plataforma \
  --region eu-west-1 --profile mercadofresco-dev

Les cinc mesures que fan que això sigui segur. Subxarxes privades: sng-mercadofresco-datos no té ruta a internet, i una memòria cau mai no ha de ser accessible des de fora —els incidents històrics de Redis exposat són nombrosos i greus—. Grup de seguretat dedicat: sg-mercadofresco-cache permet el port 6379 només des de sg-mercadofresco-tienda i des del rol de les Lambda, referenciant grups de seguretat i no rangs d'IP, com a 03-02. Xifratge en repòs i en trànsit amb alias/mercadofresco-datos, en mode required, perquè preferred acceptaria connexions sense TLS i això converteix el xifratge en opcional de fet. RBAC: la botiga rep un usuari que pot llegir i escriure catalogo:* i sesion:* però no pot executar FLUSHALL, KEYS ni CONFIG, que és el mínim privilegi de 04-01 aplicat a la memòria cau. I credencials a Secrets Manager, com tot des de 04-03, mai en variables d'entorn en clar.

Mètriques, alarmes i el mesurament de l'abans i el després

Mètrica	Què indica	Alarma suggerida
`CacheHitRate`	Percentatge d'encerts	< 80 % durant 15 min
`Evictions`	Claus expulsades per falta de memòria	> 0 sostingut
`DatabaseMemoryUsagePercentage`	Memòria usada respecte a `maxmemory`	> 80 %
`CPUUtilization` / `EngineCPUUtilization`	Càrrega del procés Redis	> 70 %
`CurrConnections`	Connexions obertes	Pujada anòmala
`ReplicationLag`	Retard de la rèplica	> 1 s

Dues mereixen explicació. Evictions més gran que zero de manera sostinguda és sempre un problema: Redis està esborrant claus que encara no havien caducat perquè no li'n cap més, la taxa d'encerts cau i la càrrega torna a Aurora; la solució és més memòria o menys dades, no ignorar-ho. I EngineCPUUtilization és més informativa que CPUUtilization perquè el procés és fonamentalment monofil: un node amb 4 vCPU pot mostrar un 25 % de CPU total amb el fil del motor al 100 %.

El mesurament de l'abans i el després, amb els taulers del mòdul 5:

Mètrica	Origen	Abans	Després
`TiempoConfirmacionPedido` p99	`MercadoFresco/Tienda`	880 ms	310 ms
Latència de la fitxa de producte	X-Ray	240 ms	28 ms
Consultes/min a Aurora (catàleg)	`AWS/RDS`	4.100	215
ACU mitjanes d'Aurora	`AWS/RDS`	2,4	1,5
`CacheHitRate`	`AWS/ElastiCache`	—	94,8 %

Aquest és el moment de recordar per què el mòdul 5 anava abans que el 6: sense aquestes mètriques, cap de les quatre decisions d'aquest mòdul no es podria defensar davant la direcció amb dades. La latència de la fitxa és el que el client nota; la resta és el que convenç qui signa la factura.

MemoryDB i DAX: quan no és ElastiCache

Servei	Què és	Quan
ElastiCache	Memòria cau en memòria; les dades es poden perdre	Desar una font de veritat que és en un altre lloc
MemoryDB	Base de dades en memòria duradora, compatible amb Redis	Quan Redis és la font de veritat i no pot perdre dades
DAX	Memòria cau específica de DynamoDB, mateixa API	Lectures repetitives molt intenses sobre DynamoDB

MemoryDB replica cada escriptura en un registre transaccional distribuït en diverses AZ abans de confirmar-la, amb durabilitat comparable a la d'una base de dades, i costa força més. MercadoFresco no ho necessita: el catàleg és a Aurora i la cistella a DynamoDB, així que la memòria cau sempre es pot repoblar. DAX ja es va descartar a 06-02: la cistella no té lectures repetitives —cada client llegeix la seva—, així que la taxa d'encerts seria baixa, i a més ElastiCache serveix dades de diverses fonts mentre que DAX només entén de DynamoDB.

Costos i estalvi mesurat

Concepte	Quantitat	Cost mensual
`cache.t4g.medium` primari	730 h × 0,073	53,29 USD
`cache.t4g.medium` rèplica	730 h × 0,073	53,29 USD
Còpies de seguretat (5 dies)	~3 GB	0,25 USD
Transferència entre AZ	Rèplica	~2 USD
Total ElastiCache		≈108,83 USD

I el que retorna, mesurat a la factura d'Aurora del mes següent:

Concepte	Abans	Després	Diferència
ACU mitjanes d'Aurora	2,4	1,5	−0,9 ACU
Cost de còmput d'Aurora	210 USD	131 USD	−79 USD
E/S d'Aurora	36 USD	22 USD	−14 USD
Cost d'ElastiCache	0	109 USD	+109 USD
Net			+16 USD/mes

Convé ser honest: la memòria cau no es paga sola en euros, costa 16 USD nets al mes. El que compra és la latència de la fitxa dividida per vuit —de 240 ms a 28 ms, que el client percep—, un marge de capacitat a Aurora que abans no existia per absorbir el pic del divendres, i les sessions distribuïdes que permeten a l'ASG escalar i reduir-se sense expulsar ningú. Com a Aurora, la justificació no és l'estalvi: és el que es compra amb la despesa.

Neteja. En acabar de practicar: aws elasticache delete-replication-group --replication-group-id <id>, amb --final-snapshot-identifier si vols conservar les dades. Un grup oblidat amb dos nodes són més de 100 USD al mes per res. Comprova amb Cost Explorer que l'etiqueta Componente=cache desapareix el mes següent.

Errors Habituals i Consells

Deixar que una fallada de la memòria cau trenqui la botiga. L'error més greu i el més habitual. Tota operació de memòria cau va embolcallada en try/except i amb temps d'espera curt. Una memòria cau caiguda degrada el rendiment; mai la disponibilitat.

Desar el resultat a la memòria cau abans de confirmar-lo a la base de dades. Base de dades primer, memòria cau després. A l'inrevés, una fallada intermèdia deixa a la memòria cau una dada que mai no va existir.

Actualitzar la memòria cau en lloc d'esborrar-la en invalidar. Esborrar és idempotent i senzill; actualitzar pot deixar un objecte parcialment escrit que se serveix com a bo durant una hora.

Fer servir la memòria cau com a font de veritat de l'estoc. Ja està dit amb tota claredat: l'estoc real és transaccional a Aurora. La memòria cau només filtra intents evidents.

Ignorar Evictions. Un valor sostingut per damunt de zero significa que Redis esborra claus vives per falta de memòria. La taxa d'encerts cau i la càrrega torna a la base de dades, amb la qual cosa la memòria cau deixa de complir la seva funció mentre se'n continua pagant.

Executar KEYS * en producció. Recorre tot l'espai de claus i, com que Redis és essencialment monofil, bloqueja el servidor mentre ho fa. Es fa servir SCAN, que itera per lots. El millor és que el RBAC prohibeixi KEYS directament.

Posar claus sense TTL. Una clau sense caducitat no se'n va mai. Amb prou claus així la memòria s'omple, amb la qual cosa comencen les expulsions. La regla és simple: tota clau porta TTL, llevat d'excepció justificada i documentada.

Desar dades personals sense pensar-hi. Una memòria cau és una còpia més de dades personals subjecta al RGPD: cal xifrar-la, restringir-hi l'accés i poder esborrar-la davant d'una sol·licitud de supressió. Desa identificadors i preferències, no adreces ni dades de pagament.

Consell: mesura la taxa d'encerts per tipus de clau, no només la global. Un 94 % global pot amagar un 99 % al catàleg i un 40 % als llistats, i aquest 40 % indica un TTL mal triat o un patró que no es repeteix prou per merèixer memòria cau.

Consell: prova el mode degradat. Apaga la memòria cau en preproducció amb càrrega i comprova que la botiga continua funcionant, més lenta però funcionant. Si cau, la memòria cau s'ha convertit en una dependència crítica sense que ningú no ho decidís.

Exercicis

Exercici 1: dissenyar la política de memòria cau d'una funcionalitat nova

MercadoFresco llança «la meva llista habitual»: una pantalla que mostra els 20 productes que un client més ha comprat els últims 6 mesos, amb el preu actual, la disponibilitat i una marca si estan en oferta. Calcular-la a Aurora exigeix agregar l'historial del client (1,2 s) i consultar preu i estoc de 20 productes.

Dissenya l'estratègia: què es desa a la memòria cau i amb quina clau, quin TTL per a cada peça, quin patró fas servir per a cadascuna, què s'invalida i quan, com evites l'estampida el dilluns al matí, i quina estructura de Redis tries per a cada element. Justifica per què no desas la resposta completa de la pantalla en una sola clau.

Exercici 2: diagnosticar una memòria cau que no ajuda

Dues setmanes després de desplegar la memòria cau, les mètriques són aquestes: CacheHitRate 41 %, DatabaseMemoryUsagePercentage 97 %, Evictions 8.400 per hora, EngineCPUUtilization 88 %, CurrConnections 2.900 i creixent, i la latència p99 de la botiga ha empitjorat respecte d'abans de la memòria cau. Es descobreix a més que l'equip desa els resultats de cerca amb clau busqueda:<text complet>:<filtres> i TTL de 24 hores.

Respon: (a) quina és la causa arrel i com la dedueixes de les mètriques; (b) per què la latència ha empitjorat en lloc de millorar; (c) quin paper juga CurrConnections; (d) quatre mesures ordenades per impacte; (e) quina política hauria evitat el problema des del disseny.

Exercici 3: tancar el cercle de l'estoc

Escriu el flux complet d'«afegir a la cistella i confirmar la comanda» per a una caixa de maduixes de la qual queden 3 unitats, indicant a cada pas quin magatzem hi intervé (ElastiCache, DynamoDB, Aurora), quin tipus de consistència es fa servir i per què. Ha de cobrir: mostrar la fitxa amb «últimes unitats», afegir a la cistella, el pas a pagament, la confirmació amb descompte d'estoc, i què se li mostra a un client que arriba tard. Indica també què passa a cada pas si ElastiCache cau en aquell moment.

Solucions

Solució 1

No es desa la pantalla completa en una sola clau perquè barreja peces amb ritmes de canvi radicalment diferents: la llista de productes habituals canvia com a molt un cop al dia, però el preu i la disponibilitat canvien cada pocs minuts. Amb una sola clau cal triar entre un TTL curt —que malgasta l'agregació cara recalculant-la constantment— o un de llarg —que mostra preus obsolets—. La regla general és desar per ritme de canvi, no per pantalla.

Peça	Clau	Estructura	TTL	Patró	Invalidació
Llista de SKU habituals	`habitual:v1:<id_cliente>`	Conjunt ordenat (puntuació = compres)	24 h ± 1 h	Cache-aside amb bloqueig	En confirmar una comanda, `ZINCRBY` incremental
Fitxa de producte	`catalogo:v3:producto:<sku>`	Cadena JSON	1 h ± 5 min	Cache-aside	En canviar el preu
Estoc aproximat	`stock:aprox:<sku>`	Comptador	30 s	Write-through a la càrrega	No
Marca d'oferta	`ofertas:v1:activas`	Conjunt	10 min	Cache-aside	En publicar campanya

La pantalla es compon llegint el conjunt ordenat (una operació) i després les 20 fitxes amb una sola crida MGET, no vint GET: la reducció de viatges de xarxa és el que converteix 20 × 0,3 ms en 0,4 ms.

Estampida del dilluns al matí: el risc és que milers de claus habitual:* caduquin alhora. Es mitiga amb les tres tècniques combinades: TTL aleatoritzat ±1 hora, bloqueig de repoblació amb SET NX EX perquè només un procés agregui per client, i —atès que l'agregació costa 1,2 s— un refresc anticipat programat de matinada per als clients més actius, que arriben al matí amb la clau ja calenta.

Incremental en lloc de recalcular: en confirmar una comanda, en lloc d'invalidar la llista es fa ZINCRBY habitual:v1:<cliente> <unitats> <sku>. La llista es manté actualitzada sense tornar a executar mai l'agregació d'1,2 s, llevat que la clau caduqui de debò. És el millor ús d'un conjunt ordenat de tota la lliçó.

Solució 2

(a) Causa arrel: la memòria cau de resultats de cerca. Les mètriques ho diuen en cadena. La clau busqueda:<text complet>:<filtres> té cardinalitat pràcticament infinita: cada combinació de text lliure i filtres genera una clau nova que gairebé ningú no repetirà. Amb TTL de 24 hores, aquestes claus s'acumulen sense parar fins a omplir la memòria (DatabaseMemoryUsagePercentage 97 %), i aleshores Redis comença a expulsar (Evictions 8.400/h) —i expulsa també les claus del catàleg, que sí que eren útils—. D'aquí el CacheHitRate del 41 %: es desa moltíssim que no es reutilitza i es perd el que sí. És el cas de manual de desar dades que es llegeixen un sol cop.

(b) Per què la latència ha empitjorat. Ara cada petició paga dos costos en lloc d'un: primer consulta Redis, falla el 59 % de les vegades, i després consulta Aurora igualment. A això s'hi suma que Aurora rep gairebé la mateixa càrrega que abans —perquè els encerts útils s'han enfonsat— amb la qual cosa no ha millorat la seva latència, i que el node de Redis està saturat (EngineCPUUtilization 88 %), així que fins i tot les operacions de memòria cau són lentes. Una memòria cau amb mala taxa d'encerts és pitjor que no tenir-ne: afegeix latència i no treu càrrega.

(c) CurrConnections creixent. Indica que les connexions no s'estan reutilitzant: o falta un pool de connexions, o cada invocació Lambda n'obre una de nova i no la tanca. Cada connexió consumeix memòria del node —agreujant el problema de memòria— i CPU al fil del motor. Amb 2.900 connexions i creixent, el node acabarà rebutjant connexions noves.

(d) Quatre mesures per impacte.

Deixar de desar les cerques de text lliure. És la causa arrel i corregir-la allibera memòria de seguida. Si es vol desar la cerca, només les consultes més freqüents —el top 100 mesurat als registres— amb TTL de minuts, no les 400.000 combinacions possibles.
Configurar la política d'expulsió adequada (allkeys-lru o volatile-lru) i revisar maxmemory. Amb LRU, almenys s'expulsa el menys usat en lloc del que toqui.
Introduir un pool de connexions amb límit màxim a l'aplicació i a les Lambda, reutilitzant el client entre invocacions.
Revisar el dimensionament un cop corregit l'anterior: si només amb el catàleg i les sessions la memòria continua per damunt del 80 %, cal pujar de tipus de node.

(e) La política de disseny que ho evita. Dues regles explícites, escrites abans de la primera línia de codi. Primera: només es desa el que es llegeix moltes més vegades de les que s'escriu, i aquesta proporció es mesura abans de desar —el catàleg era 4.100:1; una cerca de text lliure és aproximadament 1:1—. Segona: tota clau té TTL acotat i tota família de claus té un límit de cardinalitat conegut; si no es pot acotar quantes claus diferents generarà un patró, no es desa amb aquest patró. Afegir una alarma sobre Evictions > 0 des del primer dia hauria avisat en hores en lloc de en setmanes.

Solució 3

1. Mostrar la fitxa amb «últimes unitats». ElastiCache, consistència eventual. Es llegeix catalogo:v3:producto:PESC-FRES-002 i stock:aprox:PESC-FRES-002 (TTL 30 s). Si el comptador és 3, es pinta «queden poques unitats». Un desfasament de 30 segons aquí no fa mal a ningú. Si ElastiCache cau: fallada de memòria cau, es llegeix d'Aurora, la fitxa triga 240 ms en lloc de 28. Funciona, més lent.

2. Afegir a la cistella. DynamoDB, escriptura a mercadofresco-carritos amb UpdateItem, més una actualització del hash carrito:rapido:<cliente> a ElastiCache per pintar la capçalera. No es descompta estoc: afegir a la cistella no reserva res, perquè reservar en afegir provoca que cistelles abandonades bloquegin producte real. Es fa un DECRBY sobre stock:aprox només com a filtre orientatiu si la política de negoci ho demana, acceptant que és aproximat. Si ElastiCache cau: la cistella es desa igualment a DynamoDB —que és la veritat— i la capçalera es pinta llegint de DynamoDB. No es perd res.

3. Pas a pagament. DynamoDB amb lectura fortament consistent (ConsistentRead=True) de la cistella: d'aquesta lectura depèn el que es cobra, així que no serveix l'eventual. Es recalculen els preus llegint d'Aurora, no de la memòria cau, perquè l'import que es cobra no pot basar-se en un preu de fins a una hora d'antiguitat. Si ElastiCache cau: no afecta, aquest pas no la fa servir.

4. Confirmació i descompte d'estoc. Aurora, transacció amb consistència forta, i és l'únic pas que decideix:

BEGIN;
UPDATE stock SET unidades = unidades - 3
 WHERE sku = 'PESC-FRES-002' AND unidades >= 3;   -- ha d'afectar 1 fila
-- si afecta 0 files: ROLLBACK i rebutjar la comanda
INSERT INTO pedidos (...) VALUES (...);
INSERT INTO lineas_pedido (...) VALUES (...);
COMMIT;

Després del COMMIT, i només després, s'invalida stock:aprox:PESC-FRES-002 a la memòria cau i es fa ZINCRBY al rànquing del divendres. L'ordre és el de sempre: font de veritat primer, memòria cau després. Si ElastiCache cau: la comanda es confirma correctament; el comptador aproximat quedarà desfasat fins que caduqui als 30 segons, sense cap conseqüència.

5. El client que arriba tard. Va veure «queden poques unitats» perquè va llegir la memòria cau, va afegir a la cistella i, en confirmar, l'UPDATE afecta 0 files perquè un altre client s'ha endut les tres caixes. La resposta correcta és no confirmar la comanda i mostrar un missatge clar —«les maduixes s'han esgotat mentre completaves la comanda»— amb el suggeriment d'un producte equivalent i l'opció de continuar sense aquell article. Mai no es confirma una comanda basant-se en una lectura de memòria cau.

El principi que recorre els cinc passos, i que és la síntesi del mòdul sencer: eventual per mostrar, forta per decidir. La memòria cau accelera el que el client veu; la transacció d'Aurora decideix el que el client compra. I cada magatzem té un mode de fallada acotat: si la memòria cau cau, tot continua funcionant més lent; si DynamoDB cau, es perden cistelles però no comandes; només si Aurora cau s'atura la venda, i per això Aurora és l'única de les tres amb sis còpies en tres zones de disponibilitat.

La capa de dades completa de MercadoFresco

Les quatre càrregues que vam diagnosticar a 06-01 ja tenen el seu motor, i cada assignació se sosté sobre un mesurament:

Càrrega	Patró mesurat	Motor	Resultat mesurat
Comandes i estoc	OLTP transaccional, SQL ad hoc	Aurora PostgreSQL	Commutació de 96 s a 20 s; rèplica de 8 s a 15 ms
Cistella i sessions	Clau-valor, 180.000 escriptures/dia	DynamoDB	78 GB → 8 GB; 51 → 8 USD/mes; sense `VACUUM`
Informes	OLAP, 6-40 M de files agregades	Redshift Serverless	4-6 min → 2-6 s; fora de producció
Catàleg	4.100 lectures/min, 94 % idèntiques	ElastiCache (Valkey)	240 ms → 28 ms; 4.100 → 215 consultes/min

graph TD
    CF["CloudFront E2QWERTY123ABC"] --> ALB["alb-mercadofresco-tienda<br/>sense sessions enganxoses"]
    ALB --> ASG["asg-mercadofresco-tienda<br/>instancies sense estat"]
    ASG --> EC["ElastiCache · mercadofresco-catalogo<br/>cataleg, sessions, ranquing, comptadors"]
    ASG --> DDB["DynamoDB · mercadofresco-carritos<br/>cistella i sessions · TTL 30 dies"]
    ASG --> AUR["Aurora · aurora-mercadofresco-pedidos<br/>comandes, estoc, cataleg · font de veritat"]
    EC -.->|fallada de memoria cau| AUR
    AUR -->|canalitzacio nocturna i integracio sense ETL| RS["Redshift · mercadofresco-analitica<br/>hechos_pedidos i dimensions"]
    DDB -.->|Streams: cistelles abandonades| S3["S3 · mercadofresco-informes-analitica"]
    S3 --> RS
    RS --> SARA["Informes de la Sara<br/>tiquet mitja, cohorts, ranquing del divendres"]

I el balanç econòmic complet del mòdul, que convé mirar de cara:

Component	Abans	Després
RDS `mercadofresco-pedidos` + rèplica	118 USD	—
Aurora Serverless v2	—	153 USD
DynamoDB `mercadofresco-carritos`	—	8 USD
Redshift Serverless	—	16 USD
ElastiCache	—	109 USD
Total capa de dades	118 USD	286 USD

La capa de dades costa 2,4 vegades més. A canvi: la latència p99 de la botiga passa de 1.900 ms a 310 ms, la commutació per error de 96 a 20 segons, els informes de la Sara de sis minuts a sis segons, la taula de sessions deixa de créixer sense control, i l'ASG pot escalar i reduir-se sense expulsar ningú. Per a una botiga que fa 900 comandes per hora al pic del divendres, amb un tiquet mitjà de desenes d'euros, 168 USD addicionals al mes és una decisió que es justifica sola. L'important és que ara està justificada amb números, i aquesta és la diferència entre arquitectura i intuïció.

Conclusió

El catàleg se serveix des de memòria. Saps per què desar a la memòria cau —latència, cost per consulta i, sobretot, protecció de la base de dades, perquè un 95 % d'encerts converteix 4.100 consultes per minut en 205 i retorna a Aurora el marge que necessitava per al pic— i saps què no s'hi ha de desar: el que canvia a cada lectura, el que exigeix exactitud momentània, el que es llegeix un sol cop i les dades personals sense una raó clara.

Coneixes Redis/Valkey davant de Memcached i per què MercadoFresco tria el primer: estructures de dades més enllà de les cadenes, rèpliques amb commutació automàtica i operacions atòmiques. Domines l'arquitectura —node, fragment, grup de rèplica, mode clúster activat i desactivat amb les seves 16.384 ranures hash i les seves etiquetes per coubicar claus, Multi-AZ amb commutació— i la decisió de començar amb el mode clúster desactivat, perquè 1,2 GB de catàleg caben de sobres en un node i afegir complexitat sense mesurament és l'error que aquest mòdul porta cinc lliçons combatent. Amb els punts d'enllaç principal, de lectura, de configuració i de node, i la regla que el de node mai no apareix a l'aplicació.

Manejes els quatre patrons de memòria cau i l'elecció raonada: cache-aside per al catàleg perquè és el més robust —si la memòria cau desapareix, la botiga continua—, write-through a la càrrega de la llotja de les 06:00 perquè el primer client no trobi la memòria cau buida, i write-behind descartat explícitament perquè perdre escriptures de negoci no és acceptable. Amb el codi complet i les seves cinc decisions: try/except en tota operació amb temps d'espera de 150 ms, clau amb versió per invalidar el catàleg sencer de cop, setex atòmic perquè no quedin claus immortals, TTL aleatoritzat i serialització depurable. I amb l'ordre que no es negocia: base de dades primer, memòria cau després, i esborrar en lloc d'actualitzar en invalidar.

Saps què és una estampida de memòria cau i les tres mitigacions —TTL aleatoritzat, bloqueig de repoblació amb SET NX EX, refresc anticipat— i reconeixes la clau calenta com el mateix problema que a DynamoDB amb un altre nom. Apliques les estructures de Redis a problemes reals: cadenes per a la fitxa, hashes per a la cistella ràpida amb HINCRBY atòmic, llistes amb LTRIM per a les últimes cerques, conjunts ordenats amb ZINCRBY perquè el rànquing del divendres es mantingui sol a cada venda, i comptadors atòmics per a l'estoc aproximat —amb l'advertiment que no admet matisos: l'estoc real continua sent transaccional a Aurora, perquè una memòria cau pot perdre dades i vendre maduixes que no existeixen significa trucar al client, reemborsar i perdre'l—.

I has tancat el cap per lligar de 03-03: amb les sessions a Redis, l'ALB no necessita sessions enganxoses, el repartiment de càrrega és uniforme, i l'ASG asg-mercadofresco-tienda pot escalar, reduir-se i reemplaçar instàncies sense expulsar ningú, perquè cap instància no conté ja res que pertanyi a un client. Tot això en subxarxes privades amb sg-mercadofresco-cache, xifratge en repòs i en trànsit en mode required, RBAC que prohibeix FLUSHALL i KEYS, credencials a Secrets Manager, alarmes sobre CacheHitRate, Evictions, EngineCPUUtilization i DatabaseMemoryUsagePercentage, i la comparació honesta amb MemoryDB i DAX per saber quan el problema no és de memòria cau. Cost: 109 USD que en retornen 93 a Aurora, i una latència de fitxa dividida per vuit.

Amb això es tanca el mòdul 6. Les quatre càrregues tenen el seu motor i cada decisió se sosté sobre un mesurament del mòdul 5: Aurora per a comandes i estoc, DynamoDB per a la cistella i les sessions, Redshift Serverless per als informes de la Sara, ElastiCache per al catàleg. La capa de dades costa 2,4 vegades més i val cada euro, i l'important és que ara es pot demostrar.

Però en repartir les dades entre quatre magatzems ha aparegut un problema nou, i aquest cop no és de rendiment. La botiga fa massa coses de manera síncrona dins de la petició del client. Quan algú prem «Confirmar comanda», el mateix fil cobra la targeta, escriu a Aurora, actualitza DynamoDB, invalida la memòria cau, avisa el magatzem perquè prepari la caixa, envia el correu de confirmació, notifica el repartidor i publica l'esdeveniment per a l'analítica. Vuit coses encadenades, i si qualsevol d'elles falla, la comanda sencera es trenca: si el proveïdor de correu triga quatre segons, el client espera quatre segons; si el sistema del magatzem està caigut, es perd una venda que estava pagada. Ja no hi ha una base de dades per consultar per arreglar-ho, perquè el problema no és a cap magatzem: és que tot depèn de tot, alhora.

Al mòdul 7, «Integració d'aplicacions», començant per 07-01, «Amazon SQS», veurem com desacoblar aquestes vuit tasques: cues perquè la comanda es confirmi tan bon punt està cobrada i la resta passi després, temes perquè un mateix esdeveniment arribi a diversos interessats sense que la botiga sàpiga qui són, esdeveniments per encaminar segons el seu contingut, i fluxos de treball per orquestrar processos llargs amb reintents i compensacions. L'objectiu és que confirmar una comanda torni a ser una sola cosa ràpida i fiable, i que la resta del món se n'assabenti al seu ritme.

Amazon ElastiCache

Contingut

Per què desar a la memòria cau, i què no s'hi ha de desar

Redis davant de Memcached

Arquitectura: nodes, grups de rèplica i mode clúster

Particionament, ranures hash, commutació per error i punts d'enllaç

Patrons de memòria cau: cache-aside, write-through, write-behind i read-through

El catàleg de MercadoFresco amb cache-aside

TTL, invalidació i coherència

Estampida de memòria cau i claus calentes

Estructures de Redis aplicades a la botiga

Comptadors atòmics i el límit de l'estoc

Sessions a Redis: adéu a les sessions enganxoses

Seguretat: xarxa, xifratge i control d'accés

Mètriques, alarmes i el mesurament de l'abans i el després

MemoryDB i DAX: quan no és ElastiCache

Costos i estalvi mesurat

Errors Habituals i Consells

Exercicis

Exercici 1: dissenyar la política de memòria cau d'una funcionalitat nova

Exercici 2: diagnosticar una memòria cau que no ajuda

Exercici 3: tancar el cercle de l'estoc

Solucions

Solució 1

Solució 2

Solució 3

La capa de dades completa de MercadoFresco

Conclusió

Curs d'AWS

Mòdul 1: Introducció a AWS

Mòdul 2: Serveis principals d'AWS

Mòdul 3: Xarxes i lliurament de contingut

Mòdul 4: Seguretat i identitat

Mòdul 5: Monitoratge i gestió

Mòdul 6: Bases de dades

Mòdul 7: Integració d'aplicacions

Mòdul 8: Eines per a desenvolupadors

Mòdul 9: Infraestructura com a codi i govern de comptes

Mòdul 10: Contenidors a AWS

Mòdul 11: Millors pràctiques i gestió de costos