Cuando se alcanza la cifra de docena de millones de usuarios y cientos o miles de transacciones por segundo, comienzan a aparecer poblemas, como por ejemplo temas de contención, lag, consultas lentas, los datos ya no caben en memoria RAM y comienzan las lecturas frecuentes sobre el disco, etc. Todo esto comienza a degradar significativamente la calidad del servicio. Siempre se puede escalar verticalmente agregando más RAM/CPU, etc. El problema es que eso tiene un límite, verticalmente no existe el infinito.

En 2011, Instagram tenía tres ingenieros y más de 25 millones de usuarios. Corrían sobre una única instancia primaria de PostgreSQL, el punto de quiebre no fue el disco: fue la RAM. Cuando los registros dejan de caber en memoria, cada escritura empieza a pegarle al disco, la latencia p95/99 se disparó, ni con replicas pudieron resolver el problema.

Pinterest había chocado contra la misma pared con MySQL, pero peor: intentaron escalar agregando tecnologías diferentes (Cassandra, MongoDB, Membase). Su conclusión: cada sistema nuevo traía modos de fallo y tradeoffs diferentes.

Volvieron a MySQL nuevamente, pero fragmentado, aplicando el patrón Database Sharding.

Entender el sharding es fundamental si trabajar con sistemas a escala.

¿Qué problema resuelve el sharding?

Antes de llegar a sharding en una base de datos relacional hay una serie de “medidas“ que se toman previamente, el sharding es el último recurso.

1. Escalar: Agregar CPU, RAM, mejorar el hardware del disco SSD, NVM, mejorar el sistema de sistema de archivos, etc.

2. Replicas: Separar las lecturas a instancias dedicadas que mediante replicación tomen los datos de la instancia de escritura y los disponibilicen. No todas las lecturas pueden ir a una replica, los datos en las réplicas están disponibles eventualmente, entonces puede haber cierto “lag“ o delay en los datos.

3. Particiones: Sigue siendo una misma instancia pero la data internamente se particiona (verticalmente), por ejemplo por fecha, entonces toda la data de julio “cae“ en una misma partición, esto genera índices más pequeños locales por partición y permite que los sistemas puedan aplicar optimizaciones como el prunning o el wise join, entre otros.

4. Sharding: Permite partir las filas de una misma tabla entre nodos independientes, también se conoce como sharding horizontal.

Cuando se aplica sharding se resuelve el problema de poder tener diferentes instancias de escritura y lectura que absorven por separado la carga de escrituras y lecturas, permitiendo redistribuir el volumen de operaciones entre distintos nodos.

Si quieres aprender más sobre diseño de sistemas y patrones te invito a visitar SACAViX System Design. Hay ejercicios reales para diseñar sistemas, preguntas de entrevistas técnicas, están los términos más usados en system design y una guía completa de 95 patrones explicados que debes conocer.

La shard key: la decisión más importante

El elemento fundamental y más importante para poder aplicar sharding es determinar la clave de partición. La elección es fundamental porque determinará posteriormente si las consultas que se realicen sean simples o extremadamente complejas.

La elección de la clave debe permitir consultas “triviales“ y evitar lo que técnicamente se conoce como “scatter-gather”.

• Triviales: Solo necesitan ir a un nodo especifico, se evita el cross-join, son simples de ejecutar.

• Scatter-Gather: No hay forma de saber en que nodo esta el dato, hay que buscarlo en varios nodos y luego unir los resultados, aumentando la complejidad del sistema y degradando su performance.

Ejemplos:

Si el shard key es el user_id y necesita la información de un usuario, solo tienes que ir al shard donde esta ese usuario alojado y listo:

SELECT * FROM orders WHERE user_id = 456

En cambio, si la clave es user_id, pero por cuestiones del negocio tienes que hacer una consulta como la siguiente, entonces la shard key correcta no sería user_id.

SELECT * FROM orders WHERE status = 'PENDING'

En este último caso, para buscar las ordenes pendientes de todos los usuarios tendrias que ejecutar la query en todos los shards y luego unificar los datos.

Propiedades de una buena shard key

Las tres principales propiedades al elegir una shard key son:

1. Alta cardinalidad: Muchos valores distintos para repartir en shards es la mejor decisión, ejemplos malos: country (son solo unos 200), status (active, inactivo), ejemplos de buenas claves: user_id, customer_id, account_number, etc.

2. Distribución uniforme: Los datos que se generan y el tráfico deben poder distribuirse lo más equitativamente posible, sino el sistema genera lo que se llaman hotspots (toda la carga concentrada en unos pocos shards).

3. Alineación con el patrón de acceso dominante: Las queries más frecuentes llevan la key en el WHERE.

4. Inmutabilidad: Una vez insertada la clave de partición no puede actualizarse / cambiarse.

El pecado capital es la hacer consultas cross-shard. Si para cargar el feed del usuario hay que preguntar a 4.000 nodos y hacer merge en la app, cambiamos un problema de escala por uno de latencia (la query tarda lo que tarda el shard más lento) y de disponibilidad (si 1 de 4.000 está caído, la query falla). Evita SIEMPRE el cross-shard y cross-join.

¿Cómo elegir a que shard va un registro?

Las estrategias más comunes son:

• Por rango: usuarios 1–1M en el Shard A, de 1M–2M en el Shard B. Fácil de razonar, escaneos por rango eficientes, pero produce hotspots: los usuarios nuevos (los más activos probablemente) caen todos en el último shard.

• Por hash: Aplicar una función hash(key) % N, con esto se reparte uniforme y son hotspots, pero aplicar módulo de N tiene un defecto: si N es el número de servidores y agregas uno, el módulo cambia para casi todas las filas y tendrías que remigrar casi toda la base; esto es un gran problema.

Para resolver el problema de poder pasar de N a N+1 nodos se pueden aplicar dos mecanismos para el rebalanceo: Consistent hashing y Jump Consistent Hash, pero quedan fuera de este artículo.

Shards virtuales

Tanto Instagram como Pinterest resolvieron el problema de agregar nuevos nodos usando el concepto de shards virtuales. Los shards virtuales permite evitar mapear las claves directamente a nodos físicos.

Sin shards virtuales se hace algo simple, ejemplo:

Tenemos 8 servidores, se enruta así:

servidor = user_id % 8

El usuario 31341 → 31341 % 8 = 5 → vive en el servidor 5.

Ahora el negocio crece y agregamos un noveno nodo. Cambiamos a % 9. El usuario 31341 ahora da 31341 % 9 = 6. Se movió de servidor. Y no es solo él: al pasar de % 8 a % 9, casi todas las filas cambian de destino. Concretamente, solo ~1/9 de las filas se quedan donde estaban; el resto hay que físicamente moverlo entre nodos. Agregar un servidor te obliga a mover la base de datos, con el sistema en producción esto es inviable. Cada vez que escalas, cambias la función de mapeo, y cambiar la función de mapeo reubica casi todo.

La solución: poner una capa en medio que nunca cambia

En vez de mapear la clave directamente al servidor, la mapeamos a un shard virtual, y ese número, por ejemplo 8192 se fija para siempre y no se vuelve a tocar jamás:

shard_virtual = user_id % 8192      // FIJO. Nunca cambia.

El divisor ahora es una constante del sistema, no el número de máquinas. El usuario 31341 da 31341 % 8192 = 6981, y dará 6981 hoy con 8 servidores y mañana con 800. La función clave→shard es inmutable.

Ahora, ¿dónde vive físicamente el shard 6981? Eso lo dice una segunda tabla, pequeña y mutable:

shard   0    – 1023  →  mysql-01
shard 1024   – 2047  →  mysql-02
...
shard 6144   – 7167  →  mysql-07 ## <<<<<
shard 7168   – 8191  →  mysql-08

El shard 6981 cae en el rango de mysql-07. Cuando agreguemos mysql-09, no tocaremos el % 8192 de nadie. Solo editaremos la tabla de ruteos: “los shards 6912–6981 ahora viven en mysql-09”. Movemos esas datos físicamente (por replicación, async) y cambiamos unas líneas del mapa, todo ocurre online.

Por qué 8192 y no 8.

El número de shards virtuales es el techo de cuántas máquinas físicas podremos tener en el futuro. Con 8192 shards podremos escalar hasta 8192 servidores (1 shard por máquina en el extremo). Se elige grande y potencia de 2 para que el % 8192 sea un simple AND de bits y para que siempre haya granularidad para repartir. Cada máquina simplemente aloja muchos shards: con 8 máquinas, 1024 shards cada una; con 64 máquinas, 128 cada una. El shard virtual es la unidad indivisible de migración.

Por qué el mapa es barato.

Ese mapa de 8192 entradas (shard → servidor) es diminuto: unos pocos KB. Cabe entero en memoria, se cachea en cada app server, y se guarda en un store altamente disponible (ZooKeeper, etcd) que notifica cambios por watch. Resolver “¿dónde está el shard 6981?” es un lookup en un ConcurrentHashMap local, sin ir a la red. Y como cambia rarísimo (solo al reshardear), la caché casi nunca se invalida.

¿Qué pasa cuando el shard no es derivable del objeto?

Supongamos ahora un escenario en el que no podemos derivar el shard directamente, por ejemplo supongamos el siguiente endpoint:

GET /orders/129474739390030303

En este caso, suponiendo el sistema está particionado por user_id no es posible a partir del id de la orden derivar el shard hacia donde está la orden, este problema tiene dos enfoques de solución:

• Directorio: Crear una tabla donde se asocie el order_id con el shard y antes de cada consulta siempre ir a este directorio global, buscar el shard y luego ir directamente. Funciona, pero agrega una llama adicional y necesita mantener consistencia entre la fuente principal y una segunda que mantenga la relación.

• Embeber en el order_id el shard: En este caso el order_id continua sigue siendo un número, pero tendrá adentro, embebido el shard. Esto se logra usando un generador de secuencia que dentro tenga ciertos bits dedicados al numero del shard, luego haciendo decoding a nivel de bits se puede acceder de forma sencilla al shard id.

¿Cómo se implementa esto en la práctica?

La implementación en realidad cualquier asistente de IA puede hacerla, voy a explicar solo temas generales para que se pueda comprender a escala general.

Cuando ya tenemos la key elegida y/o es derivable del id, entonces lo primero que tenemos que hacer es definir el mecanismo de shards virtuales, para ello se implementa una estructura en base de datos como la siguiente:

CREATE DATABASE IF NOT EXISTS shard_topology;
USE shard_topology;

-- Inventario de servidores MySQL físicos donde viven los shards.
CREATE TABLE physical_server (
  server_id   VARCHAR(32)  NOT NULL,            -- 'mysql-01'
  host        VARCHAR(255) NOT NULL,            -- 'mysql-01.internal'
  port        INT          NOT NULL DEFAULT 3306,
  role        ENUM('PRIMARY','REPLICA') NOT NULL DEFAULT 'PRIMARY',
  status      ENUM('ACTIVE','DRAINING','OFFLINE') NOT NULL DEFAULT 'ACTIVE',
  updated_at  TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
                                  ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (server_id)
) ENGINE=InnoDB;

-- El mapa que hace toda la magia: cada uno de los 8192 shards virtuales
-- apunta a UN servidor físico y a UNA base de datos dentro de él.
CREATE TABLE shard_map (
  virtual_shard SMALLINT UNSIGNED NOT NULL,     -- 0 .. 8191
  server_id     VARCHAR(32) NOT NULL,
  db_name       VARCHAR(64) NOT NULL,           -- 'shard6981'
  updated_at    TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
                                  ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (virtual_shard),
  KEY idx_server (server_id),
  CONSTRAINT fk_shard_server
    FOREIGN KEY (server_id) REFERENCES physical_server(server_id)
) ENGINE=InnoDB;

-- Un contador de versión global: se incrementa en CADA reshard.
-- La app lo consulta cada pocos segundos; si cambió, recarga el mapa.
CREATE TABLE topology_version (
  id      TINYINT NOT NULL DEFAULT 1,
  version BIGINT UNSIGNED NOT NULL DEFAULT 1,
  PRIMARY KEY (id),
  CHECK (id = 1)
) ENGINE=InnoDB;
INSERT INTO topology_version (id, version) VALUES (1, 1);

topology_version es el mecanismo de invalidación de caché. La app cachea el mapa en memoria; para saber cuándo recargar, solo hace la query de abajo (una query simple cada pocos segundos) en vez de recargar las 8192 filas constantemente.

SELECT version FROM topology_version

A nivel de aplicación este será el flujo:

user_id  --(% 8192)-->  virtual_shard  --(shard_map)-->  (server_id, db_name)
                                              |
                              server_id --> HikariDataSource (pool cacheado)
                                              |
                              getConnection() + setCatalog(db_name)

La pieza fundamental es el ShardRouter, dado un identificador es capaz de devolver la conexión a usar para acceder a los datos requeridos:

@Component
public class ShardRouter {

    public static final int NUM_VIRTUAL_SHARDS = 8192;

    private final TopologyRepository topology;
    private final ShardProperties props;

    // UN pool por servidor físico. serverId -> DataSource.
    private final Map<String, HikariDataSource> pools = new ConcurrentHashMap<>();
    // El mapa cacheado: virtual_shard -> mapping.  Se reemplaza atómico al recargar.
    private volatile Map<Integer, ShardMapping> shardMap = Map.of();
    private volatile long loadedVersion = -1;

    public ShardRouter(TopologyRepository topology, ShardProperties props) {
        this.topology = topology;
        this.props = props;
    }

    @PostConstruct
    public void init() { reload(); }

    /** Paso 1: user_id -> shard virtual. Determinista, nunca cambia. */
    public int virtualShard(long userId) {
        return (int) (Long.remainderUnsigned(userId, NUM_VIRTUAL_SHARDS));
    }

    /** Ruteo por objeto: el shard viaja embebido en los bits altos del id. */
    public int virtualShardOfObject(long objectId) {
        return (int) ((objectId >>> 46) & 0xFFFF);
    }

    /**
     * Paso 2 y 3: shard virtual -> (servidor, db) -> conexión ya posicionada.
     * El caller usa la Connection y la cierra (vuelve al pool).
     */
    public Connection connectionForUser(long userId) throws SQLException {
        return connectionForShard(virtualShard(userId));
    }

    public Connection connectionForObject(long objectId) throws SQLException {
        return connectionForShard(virtualShardOfObject(objectId));
    }

    private Connection connectionForShard(int vshard) throws SQLException {
        ShardMapping m = shardMap.get(vshard);
        if (m == null) throw new IllegalStateException("Shard sin mapear: " + vshard);

        HikariDataSource pool = pools.get(m.serverId());
        if (pool == null) throw new IllegalStateException("Sin pool: " + m.serverId());

        Connection c = pool.getConnection();
        c.setCatalog(m.dbName());   // <-- el "USE shardNNNN": salta a la base del shard
        return c;
    }

    /** Recarga mapa y pools si la versión de topología cambió (reshard). */
    @Scheduled(fixedDelayString = "${sharding.refresh-interval-ms}")
    public void refreshIfChanged() {
        long v = topology.currentVersion();
        if (v != loadedVersion) reload();
    }

    private synchronized void reload() {
        // 1. Asegura un pool por cada servidor activo.
        for (PhysicalServer s : topology.loadServers()) {
            pools.computeIfAbsent(s.serverId(), id -> buildPool(s));
        }
        // 2. Reemplaza el mapa de shards de forma atómica.
        Map<Integer, ShardMapping> fresh = topology.loadShardMap().stream()
            .collect(Collectors.toMap(ShardMapping::virtualShard, m -> m));
        this.shardMap = fresh;
        this.loadedVersion = topology.currentVersion();
        // (opcional) cerrar y quitar pools de servidores ya sin shards asignados.
    }

    private HikariDataSource buildPool(PhysicalServer s) {
        HikariConfig cfg = new HikariConfig();
        // Sin base por defecto en la URL: elegimos la BD por conexión con setCatalog.
        cfg.setJdbcUrl(String.format(
            "jdbc:mysql://%s:%d/?rewriteBatchedStatements=true", s.host(), s.port()));
        cfg.setUsername(props.getShardUser());
        cfg.setPassword(props.getShardPass());
        cfg.setMaximumPoolSize(props.getPoolSizePerServer());
        cfg.setPoolName("shardpool-" + s.serverId());
        return new HikariDataSource(cfg);
    }
}

Ejemplo de uso del Router en una app Spring Boot.

@Repository
public class PinRepository {
    private final ShardRouter router;
    private final IdGenerators ids;   // un IdGenerator por shard virtual

    public PinRepository(ShardRouter router, IdGenerators ids) {
        this.router = router; this.ids = ids;
    }

    public long create(long userId, long boardId, String title) {
        int vshard = router.virtualShard(userId);
        long pinId = ids.forShard(vshard).nextId(); // shard embebido en el id
        try (Connection c = router.connectionForUser(userId);
             PreparedStatement ps = c.prepareStatement(
                 "INSERT INTO pins(local_id, user_id, board_id, title, created_at) " +
                 "VALUES (?,?,?,?, NOW())")) {
            ps.setLong(1, pinId); ps.setLong(2, userId);
            ps.setLong(3, boardId); ps.setString(4, title);
            ps.executeUpdate();
            return pinId;
        } catch (SQLException e) {
            throw new DataAccessResourceFailureException("insert pin", e);
        }
    }

    //.....
}

En este ejemplo se usa Connection para ejecutar consultas nativas directamente, pero rompe con la integración en Spring con @Transactional, JPA etc; estos esperan un DataSource. Existe otra forma que es usando un ThreadLocal en el contexto que contenga un DataSource, para esto hay que settearlo a nivel de Thread para que pueda ser usado. En otro momento explicaremos mejor este approach (ya es un poco largo este artículo).

Espero te haya servido lo explicado acá, es realmente un lindo patrón, pero implementarlo es realmente complejo.

Según datos, Visa procesó durante 2023 un promedio de 250 millones de transacciones por día, en fechas especiales el pico de tráfico superó los 24000 TPS (Transacciones por segundo). El problema de evitar pagos duplicados no es solo responsabilidad de Visa y Master como card brands/schemes, es responsabilidad de toda la cadena de sistemas que procesan el pago, desde el comerciante hasta el banco emisor.

Manejar altos volumenes de pago lleva a las empresas de procesamiento a manejar arquitecturas distribuidas; eso implica a menudo múltiples aplicaciones que se despliegan y escalan de forma independiente, sistemas de bases de datos donde proiedades como ACID ya no son toleradas, procesamiento asincrono, etc.

Las arquitecturas distribuidas traen consigo un reto inherente que es el manejo de la transaccionalidad, pasamos a los problemas de consistencia eventual, que son potencialmente más dificiles de manejar.

En términos prácticos un monolito o una base de datos SQL única no tienen la capacidad de escalar verticalmente para manejar altas tasas transaccionales, por ello es necesario el entorno distribuido.

Idempotencia: El corazón para evitar duplicidad

Para resolver pagos duplicados, el elemento fundamental de toda entidad de procesamiento de pagos es garantizar aplicar el concepto de idempotencia al momento de recibir un pago.

Un operación se considera idempotente si cumple que al aplicarla N veces siempre se produce el mismo resultado. En matemáticas: f(f(x)) = f(x). En sistemas de pagos: procesar la misma solicitud 10 veces debe cobrarle al cliente exactamente una vez.

Para que esto funcione los sistemas que procesan los pagos deben recibir un ID único junto con la solicitud del cliente, mientras una solicitud con ese ID se este procesando NO podrá procesarse otra con el mismo ID, luego de que la operación se procesa se almacena el resultado del procesamiento del pago junto con ese ID. Si se intenta nuevamente otro pago con ese mismo ID, entonces no se procesa nuevamente y simplemente se devuelve el resultado que previamente se guardó. Decirlo como se menciona acá es simple, pero hacerlo en un sistema distribuido requiere de expertise técnico del equipo de desarrollo de la solución.

Arquitectura “estándar“ de un sistema de procesamiento de pagos

El siguiente gráfico representa en términos generales la arquitectura de un sistema de procesamiento de pagos:

Los clientes o comerciantes del sistema de procesamiento de pagos realizan solicitudes para crear pagos con tarjetas, el procesador de pagos recibe esa solicitud, luego de los controles de seguridad, acceso, tokenización, etc en el API Gateway la enruta hacia el sistema de procesa los pagos con tarjetas, este interactuará con sistemas externos para ejecutar el pago en sí y guardará en su base de datos la información del resultado del procesamiento.

Si el cliente envía un ID junto con su solicitud el Card Processor deberá guardar en el StorageDB el resultado de la transacción junto con el ID. Si se intenta procesar otro pago con ese mismo ID entonces el Card Processor no irá al sistema externo, simplemente devuelve el resultado guardado previamente. Parece simple, pero este diseño tiene problemas que no lo hacen idempotente y por lo tanto poco confiable.

Situaciones que demuestran fragilidad de este diseño:

1. El cliente envía por error con diferencia de apenas unos milisegundos la solicitud para la misma orden (con el mismo ID), pero es tan rápido que la solicitud 1 aún no se ha procesado. En estos sistemas es usual usar escalabilidad horizontal y balanceadores de carga (con Round Robbin), por lo tanto Card Processor tiene múltiples instancias, el request 1 entró por Card Processor 1 y el request 2 entró por Card Processor 3. Cómo aún no se ha comenzado a procesar en 1 entonces cuando llega a 3 este no tiene conocimiento e inicia su procesamiento, cayendo en la ejecución de un pago duplicado.

2. Otro escenario que demuestra fragilidad en este diseño es que puede tener lugar un error transitorio de red en la comunicación entre el API Gateway y el Card Processor al enviar una solictud, como API Gateway no recibe respuesta entonces realiza un retry siguiendo una estrategia de resiliencia, sin embargo el request 1 si había llegado pero nunca supo, en este caso caemos en un escenario similar al descrito en el punto 1.

3. Otros escenarios adicionales son: El StorageDB no maneja consistencia inmediata (Recomiendo leer sobre Teorema CAP/PACELC), se va a procesar el pago al sistema externo antes de peristirlo como “en curso“ en el StorageDB, etc.

Estos escenarios demuestran que nuestro sistema no es del todo idempotente.

Exlusión mututa distribuida

Si el sistema anterior fuera un monolito usariamos un mecanismo de exclusión mutua local (mutex), en Java algo como esto:

import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.locks.ReentrantLock;
import java.util.function.Supplier;

public class IdempotencyLocker {

    // Concurrent map to store a dynamic lock per each idempotency key
    private final ConcurrentHashMap<String, ReentrantLock> locks = new ConcurrentHashMap<>();

    /**
     * Executes a critical section by ensuring mutual exclusion based on an idempotency key.
     *
     * @param key    The unique transaction key (e.g., request UUID from HTTP headers)
     * @param action The business logic or code block to be executed exclusively
     * @param <T>    The return type of the action
     * @return The result produced by the action
     */
    public <T> T executeWithLock(String key, Supplier<T> action) {
        if (key == null) {
            throw new IllegalArgumentException("Idempotency key cannot be null");
        }

        // Atomically retrieves the existing lock or maps a new one if it's absent
        ReentrantLock lock = locks.computeIfAbsent(key, k -> new ReentrantLock());

        // Attempts to acquire the mutual exclusion lock
        lock.lock();
        try {
            // Execute the critical section (e.g., database verification and API third-party calls)
            return action.get();
        } finally {
            // Crucial: always release the lock inside the finally block to avoid deadlocks
            lock.unlock();
            
            // Memory leak mitigation: remove the key from the map 
            // only if no other threads are currently waiting in the queue for this lock
            if (!lock.hasQueuedThreads()) {
                locks.remove(key, lock);
            }
        }
    }
}

Cuando una transacción llega lo primero que hacemos es generar un “bloqueo“, básicamente ponemos un candado por esa clave de idempotencia y comenzamos a procesar la transacción (Creamos el pago en el StorageDB, vamos al procesador, actualizamos el resultado de la respuesta), cuando terminamos de procesar “liberamos“ el bloqueo, básicamente el candado se abre. Si un segundo intento mientra alguna transacción tiene el bloqueo entonces se pondrá en espera hasta que termine la que esta en curso. Una vez termine la que está en curso esa se inicia a ejecutar, pero como ya esta previamente guardada en la base de datos el Card Processor no lo mandará al sistema externo, simplemente devolverá el resultado que hay en la base de datos para el pago asociado a esa clave de idempotencia.

La explicación y el ejemplo de código anterior son para cuando se usa exclusión mutua local, en sistemas como el de nuestro gráfico anterior no alcanza con eso, hay que ir a un esquema de exclusión mutua distribuida, para ellos la solución más popular es usar Redis aplicando el patrón de microservicios llamado Distributed Lock, la implementación sería así:

import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import java.util.concurrent.TimeUnit;
import java.util.function.Supplier;

public class DistributedIdempotencyLocker {

    private final RedissonClient redissonClient;
    private static final String LOCK_KEY_PREFIX = "lock:idempotency:";

    public DistributedIdempotencyLocker(RedissonClient redissonClient) {
        this.redissonClient = redissonClient;
    }

    /**
     * Executes a critical section by queuing concurrent requests with the same key.
     *
     * @param key    The unique transaction key (e.g., UUID from HTTP headers)
     * @param action The business logic or code block to be executed exclusively
     * @param <T>    The return type of the action
     * @return The result produced by the action
     */
    public <T> T executeWithLock(String key, Supplier<T> action) {
        if (key == null) {
            throw new IllegalArgumentException("Idempotency key cannot be null");
        }

        String redisLockKey = LOCK_KEY_PREFIX + key;
        RLock lock = redissonClient.getLock(redisLockKey);

        boolean isAcquired = false;
        try {
            // PARAMETERS:
            // waitTime = 15s -> Concurrent requests will now QUEUE and WAIT up to 15 seconds.
            // leaseTime = 30s -> Safety lease time in Redis if the instance completely crashes.
            isAcquired = lock.tryLock(15, 30, TimeUnit.SECONDS);

            if (!isAcquired) {
                // This only triggers if the queue wait time exceeds 15 seconds (e.g., a massive timeout downstream)
                throw new IllegalStateException("Lock timeout exceeded for key: " + key + ". Queue wait time expired.");
            }

            // Execute the critical section (e.g., check DB -> call API -> save DB)
            return action.get();

        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new RuntimeException("Thread interrupted while waiting in Redis queue", e);
        } finally {
            // Only release if this specific thread holds the lock active
            if (isAcquired && lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }
    }
}

La explicación de como funciona es exactamente la misma que para la exclusión mutua local, la diferencia es que ahora el Mapa de claves de idempotencia radica en el Redis y todos los nodos de Card Processor ven el mismo valor, de esta forma no importa si el request entra por el Card Processor 1 o por el 3.

La consistencia de la base de datos

Este es un punto importante que tiene un efecto directo en las transacciones idempotentes, es importante que la fuente de datos que almacena la clave de idempotencia y el resultado tengo consistencia fuerte, si la consistencia es eventual se corre el riesgo de que Redis libere el bloqueo, se propague a procesar un request con la misma clave de idempotencia previamente encolado y al intentar leer de una replica del StorageDB el dato aún no se encuentre sincronizado.

El éxito de los sistemas idempotentes está en un potente sistema de exclusión mutua + una capa de persistencia con consistencia inmediata.

El esquema general de funcionamiento es de la siguiente manera.

Pasos:

1. El usuario/cliente envía una solicitud para crear un pago, como header envía el Idempotency Key.

2. Una instancia de Card Processor recibe la solicitud y solicita un bloqueo exclusivo en Redis.

3. Redis entrega la exclusividad de procesar el request asociado a es clave de idempotencia.

4. El Card Processor guarda en el StorageDB la clave de idempotencia junto a los datos del pago y un estado, por ejemplo: “Running“.

5. El Card Processor llama a los sistemas externos necesarios.

6. El Card Processor guarda el estado final en la base de datos.

7. El Card Processor solicita liberar la clave en el Redis, perdiendo la condición de exclusividad.

Casos marginales de error

Si bien esta es una arquitectura bien sólida para manejar idempotencia en sistemas distribuidos, existe un punto al menos donde aunque con muy baja probabilidad pueden darse ciertas condiciones que propicien un error en la adquisición del bloqueo exclusivo y junto a ella una posibilidad de ejecución de pago duplicado: Redis.

Si bien Redis es un sistema extremadamente probado no dejar de ser un sistema que puede fallar, la arquitectura más extendida que se usa es tener Redis en un esquema Master/Slave, donde los datos se escriben sobre el maestro y pueden leerse desde el maestro o de la(s) replica. En este sentido pueden fallar dos cosas 1) la replicación de Redis es async, puede que se intente leer un dato de la réplica y aun no esté disponible y 2) el primario puede tener un failover y perder datos no replicados.

Algoritmos más potentes, pero con otra complejidad como Raft puede solucionar esto, en otro artículo abordaremos sobre este tema.

Gracias por leer hasta acá.

En muchos escenarios estos problemas operativos no salen el primer día, sino con el tiempo y se manifiestan mediante fallos operativos, aumento de latencia, dificultades de coordinación entre equipos, fallos en un componente que terminan generando problemas en cascada, etc. En la mayoría de lo escenarios esto se debe a la implementación de malas prácticas a lo ancho de la plataforma y no a un componente en particular.

¿Qué problema resuelven los microservicios?

Para entender mejor esto, es importante primero revisar que problema resuelven los microservicios.

La mejor definición en mi criterio sobre el concepto de este estilo la ofrece Martin Fowler. Simplifico en el siguiente párrafo:

Es un estilo arquitectónico que estructura una aplicación como un conjunto de servicios pequeños, autónomos y acoplados de forma flexible, organizados en torno a capacidades de negocio y que se comunican unos con otros usando a menudo mecanismos ligeros de comunicación.

Este estilo viene a resolver los siguientes problemas ofreciendo las ventajas que se ilustran a continuación.

• Escalabilidad independiente: Permite escalar solo los servicios que lo necesitan, sin afectar toda la aplicación.

• Despliegues más rápidos y seguros: Cada servicio se puede actualizar sin redeployar todo el sistema, reduciendo riesgos. Mejora significativa del Time-to-Market.

• Mejor mantenimiento del código: Divide aplicaciones grandes en partes pequeñas, más fáciles de entender y modificar.

• Equipos autónomos: Diferentes equipos pueden trabajar en distintos servicios sin bloquearse entre sí.

• Aislamiento de fallos: Un error en un servicio no necesariamente impacta a todo el sistema.

• Flexibilidad tecnológica: Cada servicio puede usar el lenguaje o tecnología más adecuada para su problema.

• Evolución ágil del negocio: Permite implementar cambios rápidamente sin afectar otras áreas del sistema.

• Mejor modelado del dominio: Facilita aplicar conceptos como Domain-Driven Design, alineando servicios con capacidades de negocio.

• Gestión de la complejidad: Divide sistemas grandes en componentes más manejables.

• Optimización de recursos: Permite usar infraestructura de forma más eficiente según la necesidad de cada servicio. (Aunque es mucho mas costoso a nivel general).

Todos estos puntos suenan geniales, pero para poder lograrlos hay que evitar ciertas prácticas que ya son conocidas en el mercado como los antipatrones de la arquitectura microservicios.

Los asesinos de los microservicios

A continuación se listan los 7 asesinos fundametales de la arquitectura microservicios.

Si te sientes con suerte o quieres probar que tanto sabes de antipatrones de microservicios te invito a que visites SACAViX Learn, donde tenemos un reto especifico de 12 preguntas sobre antipatrones, es un sencillo quiz que te ayudará a verificar tus conocimientos en esta materia.

Hacer el quiz

Problema 1: La base de datos compartida (Shared database)

Es quizás el asesino más común. Ocurre cuando múltiples servicios leen y escriben en el mismo esquema de base de datos.

• Elimina la autonomía: Si el Servicio A cambia el nombre de una columna, rompe al Servicio B.

• Se pierda la libertad de elegir el motor de base de datos adecuado para cada dominio.

• Se pierde el ownership sobre los datos; al final al tener múltiples sistemas y probablemente varios equipos termina siendo poco claro quien es el dueño de cada dato.

• Limita la escalabilidad o al hacerla se corre el riesgo de un sistema pueda terminar afectando la base de datos y como consecuencia termine impactando la estabilidad de la plataforma.

El acoplamiento se termina trasladando del código a la capa de datos.

Problema 2: Monolito distribuido

Este es un clásico problema que tiene lugar en algunas implementaciones, ocurre cuando el acoplamiento es tan alto que es imposible aprovechar las ventajas claras de los microservicios relacionadas a la independencia.

• Despliegues en cascada: Se pierde la capacidad de entrega continua real. Si el Servicio A requiere la versión exacta del Servicio B para funcionar, el riesgo de error en producción aumenta exponencialmente.

• Complejidad sin beneficio: Pagas el “impuesto de red” (latencia, serialización) sin obtener la agilidad de los microservicios.

• Fragilidad de runtime: Si un servicio cae, el sistema entero colapsa porque las dependencias son rígidas y síncronas en lugar de estar desacopladas por eventos.

• Sobrecarga cognitiva: Los desarrolladores deben conocer el estado de múltiples repositorios y servicios solo para realizar un cambio pequeño en una lógica de negocio.

Al final el problema de los monolitos termina distribuido entre varios equipos, sin ventaja alguna.

Problema 3: Excesiva comunicación entre servicios (Chatty API)

Este problema es más frecuente en equipos con baja experiencia en la adopción de microservicios, cuando un equipo si experiencia comienza a migrar a microservicios es muy común convertir “cualquier cosa“ en un pequeño servicio, esto es extremadamente peligroso y conlleva a una excesiva comunicación entre componentes para resolver una solicitud.

• Latencia acumulada: El tiempo de respuesta total para el usuario es la suma de todas las llamadas internas de red, lo que genera una experiencia de usuario pobre y un apdex general degradado.

• Consumo ineficiente de recursos: Cada llamada implica negociación TLS (si existe), headers HTTP, serialización JSON/gRPC, lo que consume CPU y ancho de banda de red innecesariamente. Por otra parte conlleva a tener más servicios y por lo tanto una mayor infraestructura para mantener.

• Mayor superficie de fallo: A más llamadas, más probabilidades de que un timeout o un error 500 en un servicio intermedio rompa la transacción completa. Aunque esto es mitigable con la aplicación de patrones de estabilidad como timeout-limiters, retries o circuit-breakers se aumenta de forma innecesaria la posibilidad de fallos, siempre hay que tener en cuenta las falacias de la computación distribuida.

• Acoplamiento de interfaz: El cliente (o el servicio llamante) debe conocer demasiados detalles internos de la estructura de otros servicios para armar una respuesta completa.

La comunicación excesiva tiene lugar cuando hay demasiados servicios por una incorrecta delimitación del contexto al momento de diseñar la arquitectura.

Problema 4: El servicio dios (God service)

Este problema se evidencia usualmente cuando existe un servicio central, complejo y extremadamente fundamental en la ejecución del proceso de negocio. Es ese servicio que en algunas empresas llaman “el servicio“ o “la API“, posee lógica compleja, es grande y pocas personas lo tocan o nadie lo quiere tocar, un error en este servicio tiene alto impacto operativo para el negocio.

Algunos problemas de tener un god service son:

• Cuello de botella organizacional: Se crean colas de espera en los equipos porque todos necesitan modificar el mismo servicio para sus respectivas funcionalidades.

• Escalado ineficiente: Te ves obligado a escalar instancias gigantes de un servicio (con mucha RAM/CPU) solo porque una pequeña funcionalidad dentro de él tiene mucha carga o es tan importante que es mejor, “por si acaso“ tenerlo escalado.

• Tiempos de compilación y test largos: El servicio se vuelve tan pesado que las pruebas unitarias y de integración tardan demasiado, ralentizando el pipeline de CI/CD.

• Resistencia al cambio: El código se vuelve “espagueti” y difícil de refactorizar debido a la enorme cantidad de responsabilidades mezcladas. En ocasiones es mejor “no tocarlo“, hacerlo supone un riesgo muy grande.

Tener el servicio dios en ocasiones, durante una etapa de transición de descomposición del monolito a microservicios es una parte normal de la arquitectura, lo que NO puede ser normal es no tener la perspectiva de saber que es necesario trabajar en su mejora o descomposición hacia componentes mas simples adapatados a las capacidades del negocio.

Problema 5: Infraestructura compartida

Este problema es un elementos más general que el problema 1 (base de datos compartida), pero es usual que no solo se comparta la base de datos, en algunas implementación de microservicios también se comparte otros componentes cuyo efecto es malo para la arquitectura, ejemplos son: Nodos de despliegue (VMs, VPS, etc), sistemas de cache distribuida compartidos, como Redis, etc.

Los problemas fundamentales de compartir infraestructura son:

• Un pico de tráfico en un microservicio de baja prioridad puede agotar los recursos (CPU, memoria, I/O) y afectar a un servicio crítico alojado en el mismo nodo.

• Punto único de fallo (SPOF): Si el Redis compartido o el cluster de Kubernetes no está correctamente particionados, una mala configuración en un lugar puede afectar todo el ecosistema.

• Dificultad en la gestión de costos: Es casi imposible determinar cuánto dinero consume cada servicio individualmente si todos comparten los mismos recursos sin etiquetas o límites claros.

• Conflictos de configuración: Limitaciones en variables de entorno o versiones de librerías a nivel de sistema operativo que afectan a todos los servicios por igual.

Problema 6: Nanoservicios

Es lo opuesto al monolito, tiene lugar cuando en la arquitectura vemos aplicaciones extremadamente simples, por ejemplo: una servicio que realice un cálculo simple como tomar un monto y calcular el IVA solo sumandole el 21% de su valor, o que su lógica sea devolver la edad de una persona basado en su fecha de nacimiento, etc.

Si es demasiado simple o no cubre un contexto delimitado (DDD) es probablemente una mala idea convertirlo en un servicio. Me gusta en lo personal mirar cuantas tablas o entidades en la base de datos tiene que gestionar el servicio, si es una sola, por ejemplo Address de un User, es una red flag para tener en cuenta.

Nanoservicios implica algunos problemas importantes:

• Alta complejidad operativa: Gestionar 50 servicios para una lógica simple implica configurar 50 pipelines de CI/CD, 50 monitoreos y 50 esquemas de seguridad.

• Alta latencia: Una operación simple de negocio que debería tardar 20ms en memoria termina tardando 500ms por los saltos entre servicios (terminamos teniendo Chatty services).

• Inconsistencia de datos: Mantener la integridad de los datos entre tantos servicios pequeños obliga a usar transacciones distribuidas (Sagas) para cosas que no deberían ser tan complejas.

• Fragmentación del conocimiento: Es difícil entender el flujo completo de una aplicación cuando la lógica está repartida en piezas insignificantes de 10 líneas de código cada una.

Problema 7: Todo es un servicio

Muy relacionado con el problema anterior, es un poco más de lo mismo, cada nueva feature que se va a desarrollar se piensa como un microservicio y no como una feature en si o en última instancia, si será usado por varios componentes como una posible biblioteca reusable.

El pensar todo como un servicio termina reuniendo todo lo malo de todos los anteriores antipatrones:

• Se generan nanoservicios.

• Aumentan los costes de mantenimiento/infraestructura.

• En ocasiones se incurre en duplicidad de código.

• Se introducen puntos de falla adicionales.

• Se genera comunicación excesiva (chatty services)

No todo es un servicio, a veces solo hay que organizar un poco y ponerlo en el contexto delimitado correcto.

Espero que te haya gustado el artículo, en estos tiempos que solo se habla de AI (incluido este blog) está bueno revisar un poco sobre arquitectura.

Ahora que llegaste hasta acá, ¿quieres comprobar cuanto aprendiste? Haz el quiz sobre antipatrones de la categoría de Arquitectura.

Para un LLM, un endpoint REST tradicional es una caja negra que requiere documentación externa (OpenAPI) y una integración manual rígida. Aquí es donde surge el Model Context Protocol (MCP). MCP es el estándar que permite a los modelos de lenguaje “ver” y “tocar” la lógica de negocio de forma nativa, segura y, sobre todo, estandarizada. Es un estándar abierto que facilita la conexión de asistentes de IA con sistemas donde residen los datos, como repositorios de contenido y herramientas empresariales. Su objetivo es permitir que los modelos de lenguaje accedan a información relevante y actualizada, mejorando la calidad de sus respuestas. ​(Gracias Anthropic por esto 🩵)

En este artículo, exploraremos cómo trascender el backend REST. Utilizando el poder de Spring AI, explicaremos el proceso para exponer una API REST como un servicio MCP. Veremos cómo pasar de la exposición de datos a la provisión de herramientas dinámicas que los modelos pueden razonar, invocar y orquestar en tiempo real.

¿Qué es Spring AI?

En en artículo anterior de esta newsletter hicimos un resumen completo de los principales conceptos que debes conocer si estas empezando en este mundo como desarrollador. Te invito a que lo revises.

Compartir

Spring AI es un proyecto del ecosistema Spring diseñado para facilitar la integración de capacidades de inteligencia artificial (IA) en aplicaciones Java, especialmente aquellas basadas en Spring/Boot. Lo mejor es que proporciona una fachada única que permite interactuar con diferentes modelos; usando Spring AI puedes sin cambiar el código de tu aplicación conectarte con Open AI, Amazon Bedrock, Vertex Gemini o un modelo local en Ollama, entre otros. Y no, NO es lo que piensas, NO ES solo un cliente para conecarse a los LLM, es mucho más que eso.

De un API REST a un MCP Server

Toda aplicación creada con Spring que exponga un servicio HTTP Rest puede exponer sus endpoints por MCP, pero cambian algunos conceptos.

En el mundo REST las aplicaciones exponen endpoints, en la modernidad de MCP se llaman tools, fin de la historia, es todo.

Entonces, la forma de hacer es crear un “Controller“ pero que exponga las “tools“ en lugar de los endpoints.

Antes de mostrarte como hacerlo con un ejemplo práctico es importante conocer algunas cosas relacionadas con los tipos de transporte que soporta MCP.

• stdio: Estandar input/output, es el mecanismo más básico y simple, el servidor MCP se ejecuta localmente y es instanciado por el cliente MCP cuando necesita acceder a sus herramientas.

• Streamable HTTP: En el transporte HTTP de flujo continuo (Streamable HTTP), el servidor opera como un proceso independiente que puede gestionar múltiples conexiones de clientes. El servidor puede, opcionalmente, hacer uso de Eventos Enviados por el Servidor (SSE) para transmitir múltiples mensajes del servidor en flujo. Esto permite tanto servidores MCP básicos, como servidores con funciones más ricas que admiten streaming y notificaciones o peticiones del servidor al cliente.

Aprende más sobre como implementar un MCP Server basado en stdio en este artículo .

Dependencias

Una vez explicado los tipos de transporte, vamos a implementar nuestra API REST de ejemplo y exponer endpoints como tools. Usaremos el mecanismo de transporte streamable http.

Actualmente MCP en Spring esta en la version 2.x, pero aun esta en desarrollo (versiones M). Usaremos la version 1.x. Es importante tener en cuenta que tanto si nuestra API usa servlets o el stack reactivo podemos hacer esto, es independiente.

Dependencias principales

La principales dependencias son el starter web (para crear el API REST de toda la vida), y el mcp server webmvc, esto es importante, si estuvieramos usando webflux tendriamos que usar la dependencia correspondiente del servidor mcp.

 <dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-web</artifactId>
 </dependency>

 <dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-mcp-server-webmvc</artifactId>
 </dependency>

Controlador REST + Streamable MCP

La API REST es la misma de siempre, veamos un ejemplo en el código.

@RestController
@RequestMapping("/rates")
public class ExchangeRateController {

    private final ExchangeRateService exchangeRateService;

    public ExchangeRateController(ExchangeRateService exchangeRateService) {
        this.exchangeRateService = exchangeRateService;
    }

    @GetMapping
    public ExchangeRate getExchangeRate(
            @RequestParam("from") String from,
            @RequestParam("to") String to) {
        return this.exchangeRateService.getExchangeRate(from, to);

    }
}

Como bien se auto-explica el código es un servicio que permite haciendo GET /rates obtener la tasa de cambio de una moneda de origen a una de destino.

Ahora ¿Cómo convertirmos esto en una tools expuesta mediante MCP para los LLM puedan ejecutarla?

Para ello, en Spring AI es bien simple, esa dependencia que incluimos hace la “magia“ por detrás.

Solo debe anotar apropiadamente los métodos y listo. Me gusta para mantener el proyecto limpio no “ensuciar“ los controladores Spring con anotaciones de MCP, para ello prefiero organizar las tools en un paquete llamado “tools“, que seria el equivalente a “controller“ en una arquitectura n-capas.

En la carpeta tools, agregamos tantas como necesitemos, podemos seguir una estructura basada en recursos o como deseemos.

import com.yoandypv.exchangerate.apirest2mcp.service.ExchangeRate;
import com.yoandypv.exchangerate.apirest2mcp.service.ExchangeRateService;
import org.springaicommunity.mcp.annotation.McpTool;
import org.springaicommunity.mcp.annotation.McpToolParam;
import org.springframework.stereotype.Component;

@Component
public class ExchangeRateTool {

    private final ExchangeRateService exchangeRateService;

    public ExchangeRateTool(ExchangeRateService exchangeRateService) {
        this.exchangeRateService = exchangeRateService;
    }

    @McpTool(
            name = "getExchangeRate",
            description = "Get the exchange rate between two currencies using ISO codes (e.g., USD to EUR)"
    )
    public ExchangeRate getExchangeRate(
            @McpToolParam(description = "Source currency in ISO format (e.g., USD)")
            String from,

            @McpToolParam(description = "Target currency in ISO format (e.g., USD)")
            String to) {
        return exchangeRateService.getExchangeRate(from, to);
    }
}

Como se observa es un simple componente de Spring que inyecta el bean con la lógica del servicio (la cual es compartida con el controlador REST).

Las anotaciones @McpTool y @McpToolParam.

• @McpTool: Permite definir la herramienta (“el endpoint“), es importante tenga un nombre para que los LLM sepan como invocarlas y una descripción que sea clara y exprese exactamente lo que hace la herramienta, asi los LLM saben para que se usan.

• @McpToolParam: Para anotar los párametros, de igual forma debe ser clara para que el LLM sepa que valor debe poner cuando invoque la herramienta. Permite otras opciones como indicar si el párametro es mandatorio o no.

Configuración del servidor MCP

Es importante para que el servicio MCP funcione adecuadamente definir la configuraciones adecuadas.

spring.ai.mcp.server.name=exchange-rate-mcp
spring.ai.mcp.server.version=0.0.1
spring.ai.mcp.server.type=SYNC
spring.ai.mcp.server.protocol=streamable
spring.ai.mcp.server.stdio=false

Solo con eso ya es suficiente.

Un punto adicional es el tema de los CORS, al ser HTTP ten en cuenta que en dependencia del cliente es importante habilitar los CORS. El código del ejemplo brinda acceso a todo, pero sigue las buenas prácticas del manejo de CORS si vas a exponer la API.

Para conectar el cliente MCP como Claude, VisualStudio Code, Cursor o cualquier otro el endpoint será: http://localhost:8080/mcp.

El ejemplo completo esta disponible acá.

Un mecanismo de bloqueo funciona restringiendo el acceso a un recurso de la base de datos (como una fila o una tabla) para evitar que las transacciones simultáneas causen conflictos, como la pérdida de actualizaciones o lecturas inconsistentes. Al aplicar bloqueos, el sistema de gestión de bases de datos asegura que las operaciones se realicen de manera ordenada y que cada transacción perciba los datos en un estado consistente y válido, respetando las propiedades ACID de las transacciones.

En este artículo explicaremos los mecanismo de bloqueo más populares usados:

• bloqueo optimista

• bloqueo pesimista (compartido y exclusivo)

La explicación estará marcada por ejemplos en MySQL/InnoDB y a nivel de aplicación veremos como implementar estos mecanismos de bloqueo usando Spring Boot con JPA.

Conceptos iniciales

• Transacción: Es una secuencia de una o más operaciones que se ejecutan como una unidad lógica de trabajo. O se completan todas las operaciones (commit), o se deshacen todas (rollback).

• ACID: Son un grupo de propiedades fundamentales para entender como las bases de datos (fundamentalmente relacionales como MySQL) garantizan la fiabilidad de los datos; cada letra representa una propiedad:

  • Atomicidad: Una transacción es una unidad indivisible, se ejecuta todo o nada (concepto de transacción).

  • Consistencia: Una transacción lleva la base de datos de un estado válido a otro estado válido. Siempre se respetan las reglas y restricciones de la base de datos (por ejemplo, claves foráneas, restricciones UNIQUE, etc.)

  • Isolation (Aislamiento): Las transacciones concurrentes se ejecutan de forma independiente y no interfieren entre sí. El resultado de ejecutar transacciones concurrentemente debe ser el mismo que si se hubieran ejecutado una tras otra. Aquí es donde el bloqueo juega un papel fundamental.

  • Durabilidad:Una vez que una transacción se ha confirmado (commit), sus cambios son permanentes y sobreviven a fallos del sistema (apagones, reinicios, etc.)

• Concurrencia: Es la capacidad de que múltiples transacciones o usuarios accedan y modifiquen los mismos datos en la base de datos “al mismo tiempo”. La concurrencia puede traer problemas que buscar resolver los mecanismos de bloqueo. Los problemas se muestran a continuación:

  • Lost updates: Cuando dos transacciones intentan actualizar el mismo dato y una de las actualizaciones se sobrescribe sin ser reconocida.

  • Dirty reads: Cuando una transacción lee datos que han sido modificados por otra transacción, pero que aún no han sido confirmados (y que podrían ser rollbackeados)

  • Non-repeatable reads: Cuando una transacción lee el mismo dato dos veces y obtiene valores diferentes porque otra transacción lo modificó y lo confirmó entre las dos lecturas.

  • Phantom reads: Cuando una transacción ejecuta una consulta dos veces y obtiene un conjunto diferente de filas debido a que otra transacción insertó o eliminó filas que cumplen los criterios de la consulta.

  • Deadlocks: Una situación en la que dos o más transacciones están esperando indefinidamente a que las otras liberen un recurso que necesitan para continuar, creando un ciclo de espera.

• Niveles de aislamiento: Definen cómo se comportan las transacciones concurrentes: qué pueden ver, qué pueden modificar y qué tipos de anomalías pueden ocurrir o evitarse. MySQL a través del motor InnoDB ofrece 4 niveles de aislamiento:

  • READ UNCOMMITED: Es el más permisivo ofreciendo un menor nivel de aislamento, permite lecturas sucias (dirty reads mencionado anteriormente).

  • READ COMMITED: Solo se puede leer datos confirmados evitando lecturas sucias pero si permite lecturas no repetibles.

  • REPEATABLE READ: Es el por defecto de MySQL, evita lecturas sucias y no repetibles pero pueden tener lugar phantom reads.

  • SERIALIZABLE: Es el más restrictivo, funciona como si las transacciones se ejecutaran una tras otra, eliminando los problemas de concurrencia mencionados en el punto anterior, sin embargo este alto nivel aislamiento genera una mayor contención.

• Bloqueo a nivel de tabla: Bloquea toda la tabla de la base de datos, lo que reduce la concurrencia pero es simple de implementar.

• Bloqueo a nivel de fila: Bloquea solo las filas afectadas, permitiendo una mayor concurrencia.

Conceptos específicos de bloqueos

A continuación se muestran los conceptos específicos de bloqueo optimista y pesimista en base de datos.

Bloqueo optimista

El bloqueo optimista opera bajo la filosofía de "esperar lo mejor". No utiliza bloqueos explícitos durante la lectura de los datos. En su lugar, permite que múltiples transacciones accedan a los mismos datos libremente, y solo verifica si hubo un conflicto (es decir, si el dato fue modificado por otra transacción) justo antes de que la transacción actual intente confirmar sus propios cambios. Si se detecta un conflicto, la transacción actual se revierte y en algunos casos, si es requerido se reintenta (en el ejemplo de más adelante veremos como ejecutar estos reintentos).

Bloqueo pesimista

Este tipo de bloqueo se basa en la filosofía de "esperar lo peor". Asume que los conflictos entre transacciones concurrentes son probables y, por lo tanto, previene estos conflictos adquiriendo bloqueos explícitos sobre los datos antes de que una transacción los lea o los modifique. Esto significa que si una transacción necesita acceder a un dato, primero debe "reservarlo" (bloquearlo), impidiendo que otras transacciones lo manipulen hasta que el bloqueo sea liberado.

Para implementar bloque pesimista existe dos posibilidades:

• Bloqueo compartido (Shared lock): Permite a múltiples transacciones leer el mismo recurso simultáneamente. Pero mientras un recurso (por ejemplo una fila) tiene bloqueo compartido no se podrá adquirir un bloqueo exclusivo.

• Bloqueo exclusivo (Exclusive lock): Solo permite que una transacción tenga acceso al recurso (para escritura) en un momento dado. Nadie más puede leer ni escribir el recurso mientras esté bloqueado exclusivamente.

Comparativa útil entre bloqueos:

La clave es que en el bloqueo optimista, no se imponen bloqueos sobre los recursos durante la mayor parte del tiempo de vida de la transacción. Por eso, el bloqueo compartido y el exclusivo, al implicar una "reserva" y restricción de acceso al recurso, son por definición parte del modelo pesimista, el modelo de bloqueo pesimista al definir bloqueos a recursos por lo general genera más contención en la base de datos, lo que en sistemas de alta concurrencia puede llegar a generar problemas como mayor latencia, disminución del rendimiento, mayor consumo de recursos e incluso deadlocks; siempre hay que usarlo con cuidado :-).

Caso de estudio con MySQL/InnoDB y Spring Boot/JPA

Para poder ver como implementar bloqueo optimista y pesimista en un ejemplo práctico vamos a implementar un sencillo ejemplo en el que tenemos una tabla account que muestra el balance de una cuenta bancaria.

Esta sería la definición de la tabla:

CREATE TABLE `account` (
  `id` bigint NOT NULL,
  `balance` decimal(10,2) NOT NULL,
  `version` bigint DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

El campo version es fundamental en esta definición. El bloque optimista no es manejado directamente por una sentencia de base de datos como si existe en el pesimista, por ello debemos “manualmente“ implementar el bloqueo optimista. El campo version nos ayudará a poder saber cual fue la versión de la fila leída, su valor será incremental, lo veremos en la siguiente sección.

Por lo demás es una tabla normal en MySQL con InnoDB.

Para la parte de Spring Boot es un proyecto estándar con las dependencias de Spring Web (opcional), el driver de MySQL y Spring Data JPA.

Bloqueos en la práctica con Spring

Una vez creada la tabla le hemos realizado algunos inserts iniciales de datos.

Este es el estado antes de comenzar a experimentar.

> select * from account;
+----+---------+---------+
| id | balance | version |
+----+---------+---------+
|  1 | 1000.00 |       0 |
|  2 | 1000.00 |       0 |
|  3 | 2000.00 |       0 |
+----+---------+---------+
3 rows in set (0.01 sec)

A nivel de aplicación esta es la Entity Account:

@Entity
public class Account {

    @Id
    private Long id;

    @Column(nullable = false)
    private BigDecimal balance;

    @Version
    private Long version;

   // getters and setters
}

Especial importancia a la anotación @Version sobre el campo numérico version, esta anotación es clave en JPA para implementar bloqueos optimistas, pero ella de por si no implementa el bloqueo en si, solo permite saber al leer una fila cual es la “version“ leída.

La anotación @Version marca un campo de una entidad JPA (una clase que se mapea a una tabla de base de datos) para que actúe como un contador de versiones o marca de tiempo para esa entidad. Su objetivo es detectar si un registro ha sido modificado por otra transacción desde que fue leído por la transacción en curso. El flujo es … si se lee un registro …. se hacen cambios …. se intenta escribir y al intentar escribir difiere la versión leída indica que “alguien“ en el medio cambio el registro y es probable que el dato no sea valida, usualmente se rollbackean estos cambio y se reintenta leyendo el valor actualizado nuevamente.

Cuando ocurre la diferencia de versión al escribir se lanza la excepción OptimisticLockingFailureException, la aplicación debe estar preparada para manejar este excepción y poder reintentar de ser necesario.

El campo anota con @Version puede ser de los siguientes tipos:

• int o Integer

• long o Long

• short o Short

• java.sql.Timestamp

• java.time.Instant

En caso de que sea numérico se incrementa en uno el valor cada vez que se cambia la entidad, en caso de que ser una fecha se settea la fecha actual del sistema.

Repository

Nuestro repositorio del ejemplo es sencillo.

public interface AccountRepository extends JpaRepository<Account, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT a FROM Account a WHERE a.id = :id")
    Optional<Account> findByIdForUpdate(@Param("id") Long id);
}

Es el estándar JpaRepository, sin embargo incluye un método para buscar custom usando JPQL y lo más interesante esta anotado con @Lock.

La anotación @Lock permite explicitamente definir control más estricto sobre la concurrencia a nivel de base de datos, garantizando que un recurso (una fila o un conjunto de filas) no sea modificado (o incluso leído, dependiendo del modo) por otras transacciones mientras tu transacción lo está procesando. Puede usarse tanto para bloqueo optimista como pesimista.

En el caso de ejemplo de nuestro repository lo vamos a usar para un bloqueo pesimista con la variante de bloque exclusivo (exclusive lock).

Este bloqueo exclusivo termina generando un SELECT … FOR UPDATE.

Si habilitas en la config la property para visualizar las consultas:

spring.jpa.show-sql=true

Podrás ver al llamar este método los logs de la consulta:

Hibernate: select a1_0.id,a1_0.balance,a1_0.version from account a1_0 where a1_0.id=? for update

Esta anotación permite varias opciones, para no hacer más largo el artículo puedes ver más información acá.

Service

En el service de nuestra aplicación que permite probar ambos tipos de bloqueos tendremos la siguiente implementación.

@Service
public class AccountService {

    private final AccountRepository accountRepository;

    public AccountService(AccountRepository accountRepository) {
        this.accountRepository = accountRepository;
    }
    
    @Transactional
    public void transferWithOptimisticLock(Long accountId, BigDecimal amount) {
        Account account = accountRepository.findById(accountId)
                .orElseThrow(() -> new RuntimeException("Account not found"));

        account.setBalance(account.getBalance().subtract(amount));
        // Al commit, si otro proceso cambió la versión, lanza OptimisticLockingFailureException
    }
    
    @Transactional
    public void transferWithPessimisticLock(Long accountId, BigDecimal amount) {
        Account account = accountRepository.findByIdForUpdate(accountId)
                .orElseThrow(() -> new RuntimeException("Account not found"));

        account.setBalance(account.getBalance().subtract(amount));
        // El lock se mantiene hasta que finaliza la transacción
    }
}

Bloqueo optimista en la práctica

Si ejecutamos el método transferWithOptimisticLock obtendremos una implementación de bloqueo optimista, si entre que leemos el datos y lo manipulamos otro proceso lo modifica se lanzará una excepción al intentar escribir. Nuestra aplicación debería estar preparada para manejar la excepción, capturarla e implementar una estrategia de reintento que permita obtener la versión más fresca del dato de la base de datos y trabajar con ella. Un ejemplo de como manejar este escenario es con un código como el siguiente:

public void transferWithRetry(Long accountId, BigDecimal amount) {
    int maxRetries = 3;
    for (int i = 0; i < maxRetries; i++) {
        try {
            accountService.transferWithOptimisticLock(accountId, amount);
            return;
        } catch (OptimisticLockingFailureException e) {
            System.out.println("Retrying due to optimistic locking...");
        }
    }
    throw new IllegalStateException("Too many retries on optimistic lock");
}

Es un ejemplo sencillo pero ilustra el como debe hacerse.

Bloqueo pesimista en la práctica

En nuestro service tenemos el método transferWithPessimisticLock, como su nombre indica es para ejemplificar este tipo de bloqueo.

Este método es @Transactional y dentro hace dos cosas dentro de la transacción:

1. Invoca al método findByIdForUpdate del Repository

2. Modifica la entidad Account

Luego de que se ejecuta el método findByIdForUpdate se hace un SELECT … FOR UPDATE y las tuplas quedan bloqueadas de forma exclusiva, solo se desbloquean cuando termina de ejecutarse el método y se haga el COMMIT de la transacción; durante ese período de tiempo nadie podrá leer ni escribir en esas filas.

Si un proceso intenta acceder con otra instrucción SELECT … FOR UPDATE no lo podrá hacer y quedará en espera (causando contención); en cambio si se hace un SELECT común se obtendrán datos en dependencia del nivel de aislamiento que tenga configurado el motor de base de datos.

Como nota aclaratoria el uso de @Version en este artículo solo es necesario para el bloqueo optimista.

Espero te haya sido el útil el artículo,

Los 3 posibles resultados básicos de analizar un texto en busca del sentimiento expresado son:

• Positivo:

  Indica una actitud favorable o positiva hacia un tema, producto o servicio.

• Negativo:

  Indica una actitud desfavorable o crítica hacia un tema, producto o servicio.

• Neutro:

  No expresa una actitud clara o favorable, o es ambiguo.

Las aplicaciones de analizar sentimientos son extensas, podemos usarlo por ejemplo:

• Evaluar atención al cliente (sin tener que usar la fastidiosa encuesta a la que te derivan la mayoría de los call centers cuando terminas una consulta).

• Análisis de noticias.

• Anáslisis de redes sociales.

• Entre muchas otras, libera tu imaginación :-)

API con Spring AI y OpenAI

De Spring AI ya hemos hablando en otros artículos de esta newsletter, te recomiendo especialmente el primer artículo de esta serie donde explicamos muchos conceptos para empezar en esto de la IA como RAG, LLMs, Embeddings, Vectores, etc. Puedes acceder acá:

En este ejemplo en caso de uso para el análisis de sentimientos vamos a usar OpenAI, Spring AI 1.0.0-M8 (en el artículo referenciado usamos M6, hay cosas que vienen cambiando toda vez que no es una versión final aún), haremos uso de Spring Web ya que va a ser una API y especificamente dentro de Spring AI, usaremos el concepto de PrompTemplate que es útil en este tipo de casos de uso.

¿Qué es prompTemplate?

Un prompt es la entrada o instrucción proporcionada por el usuario a un modelo de IA para obtener una respuesta o realizar una tarea específica. Refleja las necesidades inmediatas del usuario y guía al modelo en la generación de una respuesta adecuada, en muchos casos — como el actual — necesitamos enriquecer el prompt entrado por el usuario para instruir al LLM sobre que queremos hacer con ese texto.

Definiendo un poco mejor el concepto: en Spring AI es una clase que te permite definir un prompt con variables dinámicas, de forma similar a una plantilla de texto con parámetros. Su objetivo es ayudarte a construir fácilmente prompts personalizados para enviar a un modelo de lenguaje sin tener que concatenar strings manualmente.

Ejemplo:

String template = "¿Cuál es la capital de {pais}?";
PromptTemplate promptTemplate = new PromptTemplate(template);

Prompt prompt = promptTemplate.create(Map.of("pais", "Francia"));

No hay mucha ciencia.

Dependencias de la API

El proyecto lo puedes generar usando Spring Initialzr, básicamente estas son las dos dependencias que necesitamos.

<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
 <groupId>org.springframework.ai</groupId>
 <artifactId>spring-ai-starter-model-openai</artifactId>
</dependency>

Por un lado Spring Web y por otro el starter de Spring AI para Open AI, como comentamos en el primer artículo, si queremos reemplazar por otro proveedor, solo tendríamos que cambiar la dependencia por ejemplo: spring-ai-vertex-ai-gemini-spring-boot-starter si deseamos usar el LLM de Google y obviamente ajustar las configuraciones.

Código de la API de sentimientos

La implementación de la API consta de 3 archivos principales, más la configuración del proyecto Spring Boot en sí.

La creación del bean del chat con el cual le mandaremos los prompts al LLM.

@Component
public class ChatConfig {
    @Bean
    public ChatClient chatClient(ChatClient.Builder clientBuilder) {
        return clientBuilder
                .build();
    }
}

El servicio principal, que nos permitirá recibir el texto entrado desde el controlador, armar el prompt con el template predefinido y mandar la consulta al model de Open AI.

@Service
public class SentimentAnalysisService {
        private final ChatClient chatClient;
        public SentimentAnalysisService(ChatClient chatClient) {
            this.chatClient = chatClient;
        }
        public String analyzeSentiment(String text) {
            String promptTemplate = """
                Analiza el sentimiento del siguiente texto y responde solo con: Positivo, Negativo o Neutral.

                Texto: {input}
                Sentimiento:
                """;

            PromptTemplate template = new PromptTemplate(promptTemplate);
            Prompt prompt = template.create(Map.of("input", text));

            return chatClient.prompt(prompt).call().content();
        }
}

El controlador no lo agregaré porque es trivial, al final del artículo dejo el enlace al código del proyecto.

En la configuración del proyecto solo necesitamos especificar la key de OpenAI bajo la property:

# OpenAI
spring.ai.openai.api-key=${OPEN_AI_KEY}

Siempre este tipo de claves ponla en el ambiente, así las mantienes seguras y evitas por error pushearlas a los repositorios.

Por defecto Spring AI con Open AI usado el modelo gpt-4o-mini, pero usando la property spring.ai.openai.chat.options.model puedes especificar cualquier otro disponible, por ej: gpt-4o, gpt-4-turbo, gpt-3.5-turbo. Puedes ver más opciones de configuración en la documentación oficial.

Algunos ejemplos de la respuesta de la API:

http :8080/sentiment text=="Fue genial la compra, me encanto"
HTTP/1.1 200 
Connection: keep-alive
Content-Length: 8
Content-Type: text/plain;charset=UTF-8
Date: Thu, 01 May 2025 17:36:24 GMT
Keep-Alive: timeout=60

Positivo

http :8080/sentiment text=="No estuvo a la altura"
HTTP/1.1 200 
Connection: keep-alive
Content-Length: 8
Content-Type: text/plain;charset=UTF-8
Date: Thu, 01 May 2025 17:36:43 GMT
Keep-Alive: timeout=60

Negativo

http :8080/sentiment text=="Normal, no mucho que resaltar"
HTTP/1.1 200 
Connection: keep-alive
Content-Length: 7
Content-Type: text/plain;charset=UTF-8
Date: Thu, 01 May 2025 17:36:56 GMT
Keep-Alive: timeout=60

Neutral

Por si no lo haz usado esta forma de ejecutar llamadas a la API es usando HTTPie, es simple y ligera.

Espero te haya gustado el artículo, aunque es simple creo resulta útil para continuar explorando la IA en Java.

Antes de concluir en este lugar no hablamos solo de IA, te recomiendo le des una lectura a nuesto artículo reciente sobre Java 24 y el tema de los hilos virtuales:

Nos vemos en el próximo artículo, hasta la próxima.

Vamos por el principio.

Conceptualmente Model Context Protocol (MCP) es un estándar abierto desarrollado por Anthropic que busca estandarizar la forma en que las aplicaciones de inteligencia artificial, especialmente aquellas basadas en modelos de lenguaje grandes (LLMs), interactúan con fuentes de datos y herramientas externas.

MCP funciona bajo un esquema de arquitectura Cliente/Servidor.

• Cliente MCP: Es el componente dentro del host que se encarga de la comunicación con los servidores. Cada cliente mantiene una conexión 1:1 con un servidor MCP específico.

• Servidor MCP: Es un programa que expone una fuente de datos o servicio externo a través del protocolo MCP. Actúa como adaptador, conectando con una fuente (como un sistema de archivos local, una API web, una base de datos, etc.) y presentándola de forma estandarizada al cliente MCP.

A nivel de transporte existen dos mecanismos principales para la comunicación entre el cliente y el servidor:

• stdio (entrada/salida estándar): Este método utiliza los flujos estándar de entrada y salida del sistema operativo para la comunicación. Es especialmente útil en entornos donde el cliente y el servidor se ejecutan en el mismo proceso o en procesos estrechamente acoplados. ​

• HTTP con Server-Sent Events (SSE): Este enfoque emplea HTTP junto con SSE para permitir una comunicación unidireccional desde el servidor al cliente. En este enfoque el cliente inicia la solicitud y luego el servidor puede enviar multiples solicitudes.

¿Cómo crear un servidor MCP?

Aunque en el artículo anterior hablamos un poco del tema, en este vamos a ir mas en profundidad en el tema.

Como es costumbre, usaremos Spring AI; a diferencia del artículo anterior en este caso usaremos como sistema de transporte stdio, después de crear el servidor vamos a conectarlo con MCP Inspector y con VisualStudio Code (luego hablamos más de esto, pero es super importante).

Crear un servidor MCP es básicamente exponer Tools que “hacen cosas“, lo que van a hacer estas herramientas es cualquier cosa que se te puedo ocurrir … llamar a una API externa, leer un fichero, enviar un email … cualquier cosa.

Paso 1: Crear un proyecto Spring y agregar dependencias.

La forma rápida es entrar a Spring Starter y agregar la dependencia de Model Context Protocol Server:

<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-starter-mcp-server-webmvc</artifactId>
</dependency>

Paso 2: Crear las herramientas que queremos exponer en un servicio común de Spring.

En este ejemplo creamos 2 herramientas, una que devuelve la cantidad de libros para niños y otra que dado un título devuelve la descripción del libro correspondiente.

@Tool(name = "get_books", description = "Get the total of books for children")
public int countBooks() {
  return books.size();
}

@Tool(name = "get_books_by_title", description = "Get the total of books for children")
public String getDescription(@ToolParam(description = "the book title") String title) {
 return books.getOrDefault(title, "The book was not found");
}

Paso 3: Exponer las herramientas

Para esto solo creamos un Bean de Spring con la lista de herramientas que queremos exponer:

@Bean
public List<ToolCallback> toolCallbackProvider(BookService bookService){
  return List.of(ToolCallbacks.from(bookService));
}

Paso 4: Definir la configuración correcta

spring.ai.mcp.server.name=mcp-server-example
spring.ai.mcp.server.version=0.0.1
spring.ai.mcp.server.stdio=true
spring.main.web-application-type=none
spring.main.banner-mode=off

logging.pattern.console=

Es fundamental habilitar el modo stdio en el servidor, deshabilitar los logs y el banner de Spring; sin esto no va a funcionar el servidor en el modo stdio, para usar SSE no importa el tema de los logs.

Una vez terminado el desarrollo del servidor MCP pasamos a construir el jar.

mvn package

El jar quedará en la carpeta target/. Desde ahí lo referenciaremos para ejecutarlo con java -jar path. También puedes mover el jar a otro lugar.

¿Cómo probar un servidor MCP?

Para probar un servidor MCP podemos hacerlo de varias formas, IDEs como VisualStudio Code con Github Copilot en modo agente incorporan un mecanismo para comunicarse con los servidores MCP. También existe MCP Inspector, una UI para probar.

MCP con VisualStudio Code

La combinación de MCP con VisualStudio code además de servir para poder probar los servidores es poderosa, pues permite agregar herramientas para elevar nuestra productividad como desarrolladores.

Para configurar el servidor MCP es importante tener VisualStudio code con Copilot (en la capa gratuita funciona esto) en modo agente:

Luego pulsar en el icono de Select Tools en la imagen (Ctrl + Shift + /, en Linux).

Saltará un diálogo que nos guiará para asociar el servidor MCP a VisualStudio, al final de proceso se generará un JSON de config, similar al siguiente:

{
    "mcp": {
        "servers": {
            "example-mcp-server": {
                "type": "stdio",
                "command": "java",
                "args": [
                    "-jar",
                    "/home/yoandypv/mcp-server-example/target/mcp-server-example-0.0.1-SNAPSHOT.jar"
                ]
            }
        }
    }
}

Saldrá además un pequeño menú contextual para iniciar el servidor MCP configurado.

Una vez se esta ejecutando el servidor MCP, ya podemos interactuar con el chat de Copilot y el modelo seleccionado (en esta oportunidad estoy usando Claude 3.5 Sonnet) decidirá como usar nuestras herramientas, por ejemplo:

La magia de la IA, ahora se puede poner uno creativo con las herramientas y hacerlas productivas, no como esta que es solo un ejemplo básico. Si te fijas bien ejecutó “get_books“, que es el @Tool name que especificamos en el método.

MCP Inspector

Esta es una utilidad para probar servidores MCP, que funciona igual tanto con stdio como con SSE. Esta solución permite explorar las herramientas disponibles, revisar variables de entorno, invocar las herramientas, etc.

Es una utilidad desarrollada en node. Acá puedes consultar más información de la misma.

Una vez instalada (en el link está como hacerlo) debemos ejecutarla apuntando al servidor creado, por ejemplo:

npx @modelcontextprotocol/inspector java -jar /home/yoandypv/mcp-server-example/target/mcp-server-example-0.0.1-SNAPSHOT.jar

Esto disponibilizará una interfaz web en el puerto 6274.

Solo queda abrir el enlace y tendremos acceso a todo para probar nuestro servidor MCP.

Bueno, hasta acá el artículo de hoy, espero te sea útil, el código como siempre está disponible en Github.

Si te gusta y ves útil el contenido considera apoyar mi trabajo con una contribución en Patreon.

Un elemento clave que me motivó a adentrarme en este mundo fue la posibilidad de llevar a las aplicaciones Java los diferentes casos de uso que nos ofrece la IA, en ese sentido hoy te quiero presentar Spring AI 🌱🚀.

En este artículo haremos una presentación de algunos conceptos relacionados con la IA, como estos enfoques están soportados por Spring y haremos un ejemplo completo implementando una tienda de venta de dispositivos móviles cuyo canal de ventas es un simple chat, pero existirán microservicios que se comunicarán entre ellos usando MCP. Más adelante detallaremos el problema y su solución.

Conceptos principales de la IA para desarrolladores

Si ya estás en el tema de la IA puedes saltarte esta sección.

• LLMs (Modelos de lenguaje de gran tamaño): Son modelos de aprendizaje profundo entrenados con enormes cantidades de datos para comprender y generar lenguaje humano de manera coherente. Utilizan arquitecturas como los transformadores para procesar y generar texto, siendo fundamentales en aplicaciones como chatbots y asistentes virtuales.

• RAG (Generación aumentada por recuperación ): Es una técnica que combina modelos generativos con sistemas de recuperación de información. Antes de generar una respuesta, el modelo busca en bases de datos externas información relevante, mejorando la precisión y actualidad de sus respuestas. Esto es útil para proporcionar información actualizada y específica en tiempo real. ​

• MCP (Protocolo de contexto del modelo): Es un estándar abierto que facilita la conexión de asistentes de IA con sistemas donde residen los datos, como repositorios de contenido y herramientas empresariales. Su objetivo es permitir que los modelos de lenguaje accedan a información relevante y actualizada, mejorando la calidad de sus respuestas. ​(Gracias Anthropic por esto 🩵)

• Embeddings: Son representaciones numéricas de objetos del mundo real, como palabras, imágenes o videos, en forma de vectores en un espacio de alta dimensión. Estas representaciones permiten a los modelos de aprendizaje automático procesar y analizar datos complejos de manera eficiente, facilitando tareas como la búsqueda semántica y el análisis de similitud.

• Bases de datos vectoriales: Son sistemas diseñados para almacenar y gestionar datos en forma de vectores de alta dimensión. Permiten realizar búsquedas rápidas y precisas basadas en similitud, siendo esenciales en aplicaciones que requieren recuperación eficiente de información, como sistemas de recomendación y búsqueda de imágenes. ​

• User prompt: Es la entrada o instrucción proporcionada por el usuario a un modelo de IA para obtener una respuesta o realizar una tarea específica. Refleja las necesidades inmediatas del usuario y guía al modelo en la generación de una respuesta adecuada. ​

• System prompt: Es una instrucción predefinida que establece el comportamiento general y el rol del modelo de IA durante una interacción. Define el contexto y las reglas bajo las cuales el modelo debe operar, influyendo en cómo interpreta y responde a las solicitudes del usuario. ​(Esto es clave cuando se desarrollan agentes para delimitar su ámbito de operación)

• Alucinaciones: Se refiere a respuestas generadas por modelos de IA que son incorrectas o no tienen fundamento en los datos de entrenamiento. Estas "alucinaciones" pueden ser problemáticas en aplicaciones críticas, y se están desarrollando técnicas como RAG para mitigarlas.

Si entiendes estos conceptos ya estas list@ para entender el resto del artículo.

¿Qué es Spring AI?

Sin muchas vueltas, es un proyecto más del ecosistema Spring diseñado para facilitar la integración de capacidades de inteligencia artificial (IA) en aplicaciones Java, especialmente aquellas basadas en Spring/Boot. Lo mejor es que proporciona una fachada única que permite interactuar con diferentes modelos; usando Spring AI puedes sin cambiar el código de tu aplicación conectarte con Open AI, Amazon Bedrock, Vertex Gemini o un modelo local en Ollama, entre otros. Y no, NO es lo que piensas, NO ES solo un cliente para conecarse a los LLM, es mucho más que eso.

Si te está gustando el contenido considera apoyar mi trabajo con una contribución en Patreon.

Principales características

• Compatibilidad con múltiples proveedores de modelos de IA y soporte para sus caraceterísticas principales:

  • Chat (lo usaremos en el ejemplo)​

  • Embeddings (lo usaremos en el ejemplo)​

  • Conversión de texto a imagen​

  • Transcripción de audio​

  • Conversión de texto a voz​

  • Moderación de contenido​

• API portátil y unificada: Ofrece una interfaz coherente para interactuar con diferentes proveedores de IA, admitiendo tanto operaciones síncronas como en streaming, y brindando acceso a características específicas de cada modelo.​

• Soporte para bases de datos vectoriales: Se integra con proveedores como Apache Cassandra, Azure Vector Search, Chroma, Milvus, MongoDB Atlas, Neo4j, Oracle, PostgreSQL/PGVector, PineCone, Qdrant, Redis y Weaviate, facilitando el almacenamiento y recuperación eficiente de datos embebidos.​ (en el ejemplo usaremos PgVector)

• Llamadas a herramientas y funciones: Permite que los modelos soliciten la ejecución de herramientas y funciones del lado del cliente, accediendo a información en tiempo real según sea necesario (puede ser con advisors llamando a herramientas locales a la app o remotas usando MCP).

• Observabilidad: Proporciona información sobre las operaciones relacionadas con la IA, facilitando el monitoreo y la depuración.​

• Evaluación de modelos de IA: Incluye utilidades para evaluar el contenido generado y proteger contra respuestas erróneas o no deseadas. (lo usaremos en el ejemplo)

• APIs especializadas: Ofrece una API fluida para comunicarse con modelos de chat de IA, similar a WebClient y RestClient, y una API de asesores que encapsula patrones recurrentes de IA generativa, transformando datos enviados y recibidos de modelos de lenguaje.​ (la usaremos en ejemplo)

• Soporte para memoria de conversación y generación aumentada por recuperación (RAG): Facilita la gestión del contexto en interacciones de chat y mejora la generación de respuestas mediante la recuperación de información relevante.​ (la usaremos en el ejemplo)

• Configuración automática con Spring Boot: Proporciona configuraciones predeterminadas y starters para todos los modelos de IA y almacenes vectoriales, simplificando la integración en aplicaciones Spring Boot.​

• Soporte para MCP: Tiene soporte completo para montar un cliente y servidor usando Model Context Protocol, permitiendo crear “servicios“ con lógica de negocio reusables (microservicios), pero cuya comunicación usa MCP. (la usaremos en el ejemplo)

Además de esto ofrece otro grupo de funcionalidades que puedes inspeccionar más a fondo en la página del proyecto.

Ejemplo con Spring AI: Tienda de aplicaciones móviles

Descripción del problema:

Desarrollar una tienda online cuyo canal de ventas sea por chat mediante un agente de ventas, el usuario deberá interactuar con el agente solicitando información sobre los dispositivos móviles que se venden, sus características, precio y cualquier otro detalle relevante. El agente deberá tener memoria para poder dar continuidad a la comunicación con el cliente. El cliente podrá consultar los diferentes métodos de pago disponibles para su compra y podrá realizar la compra del dispositivo de su ínteres. Para ejecutar los pagos debe crearse un servicio de pagos independiente y generico cuya comunicación con la tienda sea usando Model Context Protocol.

Puntos claves para resolver el problema:

• El canal de ventas será por chat, por lo que se require la incorporación de un LLM que tenga esta capability. Casi todos los LLM hoy permiten esto, usaremos OpenAI (Este ejemplo igual lo hice con Vertex Gemini, en el código aún están comentadas las dependencias).

• Los productos de la tienda son propios y para mejorar la calidad de las respuestas aplicaremos RAG, esto brindará información a los clientes sobre los productos a la venta. Los datos reales de los productos que venderemos serán nuestros.

• Para implementar RAG precisamos una base de datos vectorial y de la capability de embedding para texto de OpenAI (o cualquier otro modelo que lo soporte).

• Usando el modelo de OpenAI con Spring AI + PostgreSQL/PgVector vamos a convertir nuestra base de datos de productos y llevarla a un esquema vectorial.

• Para darle acceso al LLM a nuestra base de datos vectorial con la información (que seria el RAG) debemos crear un Advisor en Spring IA, el tipo de advisor para implementar RAG es QuestionAnswerAdvisor.

• Debemos restringir el contexto de nuestro chat, así no da respuestas fuera de su función que es vender móviles. Para esto usaremos un prompt de sistema al inicializar la aplicación.

• Debemos implementar un mecanismo de memoria por usuario, así nuestro chat podrá mantener una comunicación fluida con el cliente. Para esto usaremos un mapa concurrente en Java, como key del mapa el username como valor un PromptChatMemoryAdvisor. Para este ejemplo la memoria de nuestro chat la montamos en la ram, pero pudieramos usar alguna otra implementación como implementar la memoria en la base de datos vectorial.

• Como los pagos los tiene que procesar un servicio dedicado crearemos una api de payments que expondrá dos herramientas (en MCP / Spring AI las funcionalidades expuestas por la API se llaman Tools); una funcionalidad para listar los métodos de pagos disponibles y otra para ejecutar el pago. (En este ejemplo las funcionalidades están mockeadas, pero pueden ser perfectamente reales).

• Tenemos que implementar el cliente MCP en la tienda para que se conecte a nuestro servidor MCP de payments.

Arquitectura de la aplicación

A alto nivel son dos servicios (la tienda y el servicio de pagos), el usuario se conecta a la tienda vía http/rest (en chat real seguro mejor usar algo como websockets), la tienda interactuará con el LLM, la base de datos vectorial y si el cliente necesita comprar con la herramienta de pagos vía MCP.

Cuando el usuario hace una pregunta (a partir de ahora un prompt de usuario) entra en juego la magia del RAG, el flujo es como se describe en el siguiente diagrama:

Pero para poder aumentar y dar respuestas de calidad primero tuvimos que llenar nuestra base de datos vectorial con la información de nuestros productos a la venta. Para ello seguimos el siguiente flujo:

El proceso de llenar la base de datos vectorial se realiza una sola vez, en un caso de uso real tendríamos que buscar la forma de sincronizarlas. También podemos exponer la información de la base de datos SQL como una tool y consultarla directamente, pero los resultados no serán tan buenos (en mi opinión).

Bueno vamos a ver algunos snippets de código ahora. Todo esta disponible para probar en GitHub.

Código del servicio principal: mobile store

Empecemos por las dependencias necesarias. Será ante todo una aplicación web por lo que el starter web estará presente, voy a colocar solo las principales:

<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-openai-spring-boot-starter</artifactId>
</dependency>

<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-pgvector-store-spring-boot-starter</artifactId>
</dependency>

<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-mcp-client-spring-boot-starter</artifactId>
</dependency>

Creo las dependencias son bastante claras de arriba a abajo: integración con OpenAI (por defecto con el modelo gpt-4o-mini, pero puede cambiarse), le sigue la integración con la base vectorial (extensión de postgresql), y el cliente MCP para poder conectarnos al servicio de payments.

Importante es crear nuestro cliente de chat (cliente para OpenAI), inicializarlo y disponibilizarlo como un bean de Spring.

@Bean
public ChatClient chatClient(ChatClient.Builder clientBuilder, McpSyncClient paymentMcpSyncClient) {
        return clientBuilder
                .defaultSystem(systemPrompt)
                .defaultTools(new SyncMcpToolCallbackProvider(paymentMcpSyncClient))
                .build();
    }

Este cliente en realidad tiene cositas:

Con esta configuración le setteamos el prompt de sistema justo cuando lo creamos, así restringimos el scope.

.defaultSystem(systemPrompt) 

En nuestro caso le pusimos:

private String systemPrompt = """
You are an AI assistant helping people find the phone of their dreams 
in our store in Uruguay. If no information is available, simply inform 
them that there are no devices available at the moment.
""";

Con esta otra parte le hacemos la conexión al servidor MCP de payments que veremos más adelante:

.defaultTools(new SyncMcpToolCallbackProvider(paymentMcpSyncClient))

Ese paymentMcpSyncClient es este Bean.

@Bean
public McpSyncClient paymentMcpSyncClient() {

   var mcpClient = McpClient
            .sync(new HttpClientSseClientTransport("http://localhost:8081"))
            .build();
   logger.info("McpSyncClient created");
   mcpClient.initialize();
   return mcpClient;

}

Una vez creado con el codigo anterior, le dimos memoria a nuestro chat con este código:

private Map<String, PromptChatMemoryAdvisor> memoryAdvisors;  
....
this.memoryAdvisors = new ConcurrentHashMap<>();  
.....

public PromptChatMemoryAdvisor getOrCreateChatMemoryAdvisor(String user) {

        if (this.memoryAdvisors.containsKey(user)) {
            logger.info("Retrieving chat memory advisor for user {}", user);
            return this.memoryAdvisors.get(user);
        }

        this.memoryAdvisors.put(user, PromptChatMemoryAdvisor.builder(new InMemoryChatMemory()).build());
        logger.info("Creating chat memory advisor for user {}", user);
        return this.memoryAdvisors.get(user);
    }

Cada vez que un usuario hace una pregunta o inicia una conversación le creamos o reusamos su PromptChatMemoryAdvisor, de esta forma nuestra aplicación siempre tendrá contexto.

La parte principal de la aplicación es esta sección de código:

public String chat(String user, String userQuery) {

        var memory = this.getOrCreateChatMemoryAdvisor(user);

        return this.chatClient
                .prompt()
                .user(userQuery)
                .advisors(Arrays.asList(memory, this.questionAnswerAdvisor))
                .call()
                .content();
    }

Este método será invocado desde el controlador y pasará el usuario que está en la conversación y el su consulta o prompt de usuario.

La parte que falta por explicar es: this.questionAnswerAdvisor

En Spring AI existe un Advisor llamado: QuestionAnswerAdvisor, este es el encargado de conectar con nuestra base vectorial para poder hacer el RAG correctamente. Para ello al incluir la dependencia de pgVector, y proveer configuraciones de conexión a postgress automaticamente se crea en el contexto un bean llamado VectorStore (una fachada para la VectorDB incluida en la app).

Entonces el código anterior se complementa con:

private QuestionAnswerAdvisor questionAnswerAdvisor;
private final VectorStore vectorStore;
...
this.questionAnswerAdvisor = new QuestionAnswerAdvisor(vectorStore);

El controlador de la aplicación para este ejemplo se sencilla y sin relevancia para este artículo:

@RestController
@RequestMapping("/store")
public class StoreAssistantController {

    private final StoreAssistantService storeAssistantService;

    public StoreAssistantController(StoreAssistantService storeAssistantService) {
        this.storeAssistantService = storeAssistantService;
    }
    
    @GetMapping("/{user}/question")
    public String chat(@PathVariable("user") String user, @RequestParam String question) {
        return this.storeAssistantService.chat(user, question);
    }
}

Algunas properties importantes:

# La conexión a postgre/pgvector
spring.application.name=mobile-store
spring.datasource.url=jdbc:postgresql://localhost/store
spring.datasource.username=root
spring.datasource.password=root
spring.datasource.driver-class-name=org.postgresql.Driver
spring.datasource.hikari.maximum-pool-size=10

# Cuando se vaya a popular la base vectorial
spring.ai.vectorstore.pgvector.initialize-schema=true

# La clave de la API de Open AI (esta no es gratis)
spring.ai.openai.api-key=${OPEN_AI_KEY}

Código del servicio de pagos: Payment Tool (mcp server)

Como vimos, tenemos que crear un servidor MCP, en la tienda ya vimos como crear el cliente, ahora veremos como creamos un servidor MCP.

Antes de ver algo de código Spring AI tiene 3 formas principales de comunicación para MCP a nivel de transporte:

• stdio (sálida estándar, esta es útil para herramientas como claude desktop).

• SSE basado en servlets

• SSE con Webflux para variante reactiva.

En este ejemplo usamos SSE basado en servlets.

La implementación de MCP de Spring puedes consultarla acá, es interesante.

Bueno, veamos el código, empecemos por las dependencias:

<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-mcp-server-webmvc-spring-boot-starter</artifactId>
</dependency>

Como comentamos anteriormente, en un servidor MCP se exponen herramientas, las cuales son aprovechadas por el LLM para “hacer cosas“. Cuando un cliente MCP inicia se conecta al servidor y carga las herramientas disponibles para usar. En nuestro ejemplo creamos dos herramientas en un servicio de Spring.

@Service
public class PaymentService {

    private final Logger log = LoggerFactory.getLogger(PaymentService.class);

    @Tool(name = "execute_payment", description = "Execute a payment for buy a mobile")
    private String executePayment(@ToolParam(description = "the id of the mobile") String productId,
                                  @ToolParam(description = "the user") String user,
                                  @ToolParam(description = "the price of the mobile") double amount) throws JsonProcessingException {
        log.info("Executing payment id:{}, user: {}, amount:{}", productId, user, amount);

        return "Payment executed successfully";
    }


    @Tool(name = "get_card_brands", description = "Get the card brands or payment methods available")
    private String getCardBrandsAvailable() {
        return "Visa, Mastercard";
    }
}

Las tools se crean anotando métodos con @Tool y es importante proveer una descripción precisa de lo que hace la herramienta, de esta forma el LLM sabe cuando invocar la herramienta. Los parámetros deben ser de igual forma documentados.

La creación del servidor concluye creando un bean con las herramientas que se quieren exponer:

@Bean
public ToolCallbackProvider toolCallbackProvider(PaymentService paymentService) {
        return MethodToolCallbackProvider.builder()
                .toolObjects(paymentService)
                .build();
    }

Con esto ya nuestro servidor MCP está disponible.

Este proyecto está 100% disponible en Github, espero te sirva este artículo, aprendí muchas cosas nuevas programando esta solución, espero te sea útil.

Si te gusta el contenido considera apoyar mi trabajo con una contribución en Patreon.

• Repositorio de la tienda: https://github.com/yoandypv/spring-ai-mobile-store

• Repositorio del servidor MCP de pagos: https://github.com/yoandypv/spring-ai-mcp-payments-server

Disfruta 🚀🚀

• La introducción de hilos ligeros y baratos controlados por la JVM para optimizar los clásicos hilos de plataforma; conocidos inicialmente como fibras, ahora hilos virtuales.

• Proveer un mecanismo de concurrencia estructurada a la plataforma Java.

• Adaptar ThreadLocal para los hilos virtuales a través de valores de ámbito, en inglés Scoped Values.

Como dato interesante los hilos virtuales son daemon threads.

En Java 21 se liberó en versión final la JEP 444 que dotó a la JDK de hilos virtuales “estables“, pero … aún quedaba el problema del pinning por resolver, sino estás muy al tanto te recomiendo leas este artículo en el blog.

Para entender los hilos virtuales debes conocer 4 conceptos básicos:

• Carrier threads: Son los hilos de plataforma sobre los que se ejecutan los hilos virtuales, por defecto se crean tantos hilos de plataforma como indique Runtime.getRuntime().availableProcessors(), obviamente esto es “tunneable“.

• Mount: Es el proceso mediante el cual el Virtual Thread Scheduler asigna la ejecución de un hilo virtual a uno de plataforma (lo coloca sobre un carrier thread para que se ejecute).

• Unmount: Lo contrario a lo anterior, si un proceso virtual entra en un estado de espera entonces el planificador desmonta el hilo virtual para liberar el hilo de plataforma, evitando que permanezca bloqueado y pueda ser usado en otra tarea.

• Pinning: Es el problema que ocurría antes de Java 24 en el que un VirtualThread en ciertas condiciones se quedaba montado en el Carrier thread, evitando la liberación del recurso.

Con estos conceptos y esta imagen podrás ver como funcionan los hilos virtuales sobre los de plataforma (carrier threads).

Java 21 vs 24: Anclaje resuelto

Para ver si se resolvió el problema del pinning hemos realizado un experimento con un bloque de código que produce pinning en Java 21 usando la primitiva synchronized de Java.

El ejemplo:

private static final Object lock = new Object();

.....

try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (int i = 0; i < 100; i++) {
        executor.submit(() -> {
            synchronized (lock) {
                System.out.println(Thread.currentThread());
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        });
    }
}

En resumen creamos un executor que ejecutará cada tarea enviada en un hilo virtual. Le mandamos un grupo de tareas con un bloque sincronizado por una variable global.

Para ver si la ejecución de un código produce pinning tenemos la opción: -Djdk.tracePinnedThreads=full.

Para el experimento hemos ejecutado el código anterior, con la flag activa en la JDK 21 y 24, además visualizamos la ejecución con la herramienta de profiling Visual VM.

Java 21: Con pinning

Para la prueba con Java 21 hemos usado la siguiente versión.

openjdk version "21.0.6" 2025-01-21 LTS
OpenJDK Runtime Environment Corretto-21.0.6.7.1 (build 21.0.6+7-LTS)
OpenJDK 64-Bit Server VM Corretto-21.0.6.7.1 (build 21.0.6+7-LTS, mixed mode, sharing)

Al ejecutar el bloque de código en la salida estándar tenemos:

VirtualThread[#27]/runnable@ForkJoinPool-1-worker-2
VirtualThread[#27]/runnable@ForkJoinPool-1-worker-2 reason:MONITOR
    java.base/java.lang.VirtualThread$VThreadContinuation.onPinned(VirtualThread.java:199)
    java.base/jdk.internal.vm.Continuation.onPinned0(Continuation.java:393)
    java.base/java.lang.VirtualThread.parkNanos(VirtualThread.java:635)
    java.base/java.lang.VirtualThread.sleepNanos(VirtualThread.java:807)
    java.base/java.lang.Thread.sleep(Thread.java:507)
    com.yoandypv.vt.PinnedThreadsExample.lambda$sample2$1(PinnedThreadsExample.java:50) <== monitors:1
    java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
    java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
    java.base/java.lang.VirtualThread.run(VirtualThread.java:329)
VirtualThread[#33]/runnable@ForkJoinPool-1-worker-8
VirtualThread[#35]/runnable@ForkJoinPool-1-worker-8
VirtualThread[#32]/runnable@ForkJoinPool-1-worker-7
VirtualThread[#37]/runnable@ForkJoinPool-1-worker-7
......

Esta parte es importante:

VirtualThread[#27]/runnable@ForkJoinPool-1-worker-2 reason:MONITOR
    java.base/java.lang.VirtualThread$VThreadContinuation.onPinned(VirtualThread.java:199)

Nos indica que en la ejecución quedaron hilos anclados, específicamente que el virtual thread #27 quedó anclado al carrier thread worker-2. Esto es un problema porque el hilo permanece ocupado y no se libera para tomar otro trabajo, el problema con esto es que afecta la escalabilidad prometida con hilos virtuales.

En el código podrás ver Continuation.onPinned esto es fundamental, los hilos virtuales se ejecutan gracias a Continuation, que es en verdad la gran revolución a mi entender de Loom, los virtual threads son solo una aplicación de la Continuations. En otro artículo hablaremos de esto.

Si vemos esta ejecución en VisualVM se ve así:

Lo más importante es que los carrier thread (workers del 1 a 8) quedan durante la ejecución en estado WAIT, lo que efectivamente representa un bloqueo. El problema del pinning esta presente.

Java 24: Bye bye pinning

Con la JDK 24 ejecutamos el experimento con el mismo ejemplo, los datos específicos de la JDK son:

openjdk version "24" 2025-03-18
OpenJDK Runtime Environment Corretto-24.0.0.36.2 (build 24+36-FR)
OpenJDK 64-Bit Server VM Corretto-24.0.0.36.2 (build 24+36-FR, mixed mode, sharing)

Al ejecutar el bloque de código en la salida estándar tenemos:

VirtualThread[#26]/runnable@ForkJoinPool-1-worker-1
VirtualThread[#103]/runnable@ForkJoinPool-1-worker-1
VirtualThread[#132]/runnable@ForkJoinPool-1-worker-2
VirtualThread[#131]/runnable@ForkJoinPool-1-worker-2
VirtualThread[#134]/runnable@ForkJoinPool-1-worker-2
VirtualThread[#133]/runnable@ForkJoinPool-1-worker-2
VirtualThread[#130]/runnable@ForkJoinPool-1-worker-1
VirtualThread[#129]/runnable@ForkJoinPool-1-worker-2
VirtualThread[#128]/runnable@ForkJoinPool-1-worker-2
VirtualThread[#127]/runnable@ForkJoinPool-1-worker-1
....

El primer punto a señalar es que no saltó el log que indica pinning al usar la flag. Si vamos al VisualVM se visualiza de esta manera:

Los carrier threads se muestran en estado Parked. El estado parked nos indica en este contexto que el scheduler desmontó el hilo virtual evitando el bloqueo del hilo de plataforma, carrier thread fue “aparcado“ y podría recibir más trabajo.

Como dijo Neil Armstrong:

Ese es un pequeño paso para el hombre; un gran salto para la humanidad.

Consideraciones

Aún no tengo del todo comprobado que el problema del pinning este resuelto en otros escenarios como los relacionados con JNI, tendremos que esperar a que madure un poco esta nueva versión y sea sometida a más pruebas. Pero ya es un salto fundamental que lo hayan resuelto para synchronized.

Nos vemos en el próximo, comparte si crees puede ayudar a otros a aprender.

Las bases de datos SQL surgieron como una manera para estructurar adecuada y normalizada-mente la información en una época donde el almacenamiento era muy costoso y la normalización era una solución para el ahorro de espacio. Aún con el creciente abaratamiento del almacenamiento son mayoría probablemente los casos de uso donde un motor SQL tradicional como MySQL o Postgres se ajuste mejor.

Sin embargo muchos desarrolladores solo usan el motor de base de datos y algunos no tienen claro como funciona por dentro. En esta entrada te intentare explicar como funciona y se almacena la información en SQL, en este caso tomaremos como punto de referencia MySQL con InnoDB.

Aprenderás:

• ¿Cómo se guarda la información en MySQL/InnoDB?

• ¿Qué es una página en el contexto de MySQL?

• ¿Cómo se organizan internamente los datos?

• ¿Qué es un índice y cual es su importancia?

• ¿Cuáles son los tipos de índices que existen?

• ¿Cómo funcionan los índices internamente?

• ¿Cómo podemos analizar las consultas y optimizarlas?

Te invito a continuar leyendo este interesante artículo en mi blog personal. Es gratis.

Me tomó bastante tiempo hacerlo, pero aprendí y me divertí mucho, espero lo disfrutes.

Lee el artículo completo acá.

Si quieres colaborar para ayudarme a crear más contenido como este considera unirte como colaborador en Patreon.

También me puedes seguir en Youtube.

Nota: El tema del pinning no es un invalidante para usar hilos virtuales, pero si atentan contra su buen desempeño.

Los hilos virtuales son un modelo de concurrencia novedoso para Java en el cuál el manejo de los hilos deja de ser controlado por el sistema operativo y el control es tomado por la JVM, el menos el control de los hilos virtuales en sí.

Un hilo virtual se mapea 1 a muchos con respecto a los hilos de plataforma, permitiendo una mayor escalabilidad, cuando el hilo virtual no está en uso, el mismo se “desmonta“ del hilo de plataforma y lo cede para que otro hilo virtual pueda ser “montado“ y ejecutado.

El problema de los hilos pinned se da cuando bajo ciertas condiciones el hilo virtual queda montado en su carried thread, cuestión que puede terminar afectando la escalabilidad.

En la siguiente entrada de nuestro blog explicamos en profundidad este tema con un ejemplo, aprenderás como detectar esta situación y como podemos evitarla.

Te invito a que le des una lectura completa a este artículo: Los hilos virtuales y el problema del “pinning”.

Compartir

Esta semana que recién finaliza Oracle lanzó Java 23. La versión más reciente de la JDK llega con un importante número de novedades que como desarrollador deberías conocer, eso si, la mayoría de las cosas llegan en “Preview”.

Fueron presentadas al menos 7 interesantes JDK Enhancement Proposal (JEP) en esta nueva versión que no es LTS por lo que no está recomendada para entornos productivos. Por otro lado al estar muchas de las novedades en fase de preview tampoco se recomiendan para comenzar a usar.

Sin embargo es importante estar al día, porque lo que hoy sale como preview en una versión no LTS es muy probable en la próxima LTS (que será Java 25, en el 2025) sea ya una feature definitiva de Java.

A continuación te muestro las novedades mas relevantes, pero en el blog he elaborado un artículo con ejemplos en código donde vemos todo esto en profundidad. Lee el articulo completo acá.

Se liberan las siguientes JEP:

• JEP 467 - Java doc ahora soporta markdown.

• JEP 474 - ZGenerational model será usado por defecto cuando se use ZGC .
  

Continúan en fase preview:

• JEP 455 - Tipos primitos en patrones, switch e instanceof.

• JEP 466 - Cass File API.

• JEP 473 - Stream Gatherers, para crear operaciones intermedias custom cuando manejemos streams de datos.

• JEP 476 - Import modules. Tiene como objetivo poder importar de forma simple todos los módulos exportados en un paquete (disponibles según su nivel de visibilidad.)

• JEP 480 - Concurrencia estructurada (forma parte del proyecto Loom)

• JEP 481 - Scoped Values (forma parte del proyecto Loom)

• JEP 482 - Constructores flexibles (Antes llamado instrucciones antes de super)
  

Se deprecan:

• JEP 471 - (memory access methods) sun.misc.Unsafe se marco como deprecado y sera movido en el futuro. El reemplazo para sun.micUnsafe fue introducido en Java 9 con VarHandle API y en 22 se complemento con Foreign Function y Memory API.

• Retiradas las plantillas de cadena introducidas en Java 21 para un rediseño.

Compartir

Para lograr mecanismos de persistencia escalables se requiere de la adopción de tecnologías de almacenamiento de datos que así lo permitan. La elección incorrecta de un sistema de base de datos en etapas tempranas del desarrollo puede traer consigo verdaderos dolores de cabeza en el futuro.

Para elegir la base de datos deben tenerse en cuenta 3 factores principales: disponibilidad, consistencia y tolerancia a particiones que pueden tener lugar en la red de datos. Un sistema de consistencia escalable necesita ser distribuido con todo el reto que esto lleva consigo. La conjetura de Brewer convertida en teorema CAP fue extendida con el teorema PACELC por Daniel J. Abadi al incluir consideraciones de latencia y consistencia durante condiciones normales de operación.

En este artículo en nuestro blog SACAViX te damos toda la explicación.

¿ Te gusta el contenido que publicamos ?

Si es así considera ayudarme compartiendo este contenido en tus redes sociales y considera unirte como miembro en Youtube o Patreon.

Cache en Spring Boot con Caffeine

Caffeine es una de las implementaciones de cache más populares en el mundo Java, e es una biblioteca de caché de alto rendimiento, popular por su baja latencia y alta capacidad de manejo. Ofrece configuración flexible, incluyendo tamaño máximo, políticas de expiración y estrategias de manejo de memoria.

Soporta carga asíncrona de datos, expiración basada en tiempo desde el último acceso o escritura, y proporciona métricas detalladas para monitoreo del rendimiento. Caffeine es ideal para aplicaciones que requieren acceso rápido y eficiente a datos en memoria.

En nuestro canal de Youtube publicamos un interesante vídeo esta semana con un ejemplo práctico de como integrar esta librería con Spring Boot, te invito a que le des una mirada y sumes esta tecnología a tu caja de herramientas como desarrollador.

Espero que te diviertas aprendiendo con este episodio de la newsletter e invita a tus amigos para que sumen y aprendan también.

En Java en particular es común el uso de modelos (entitys), objetos de transferencia de datos (dto) y objetos planos de Java (pojos), al crear este tipo de elementos podemos hacerlo usando simples clases con atributos, getters y setters (clases con anemia) o incluso podemos agregar algo de lógica (enriquecidas). En este artículo hablaremos sobre esto.

Seguir leyendo en nuestro blog

Escalabilidad en los microservicios

Un sistema escalable es aquel que cuenta con una capacidad de adaptación y respuesta con respecto al rendimiento del mismo a medida que aumenta forma significativa el tráfico del mismo.

Un sistema es escalable si puede soportar los niveles de calidad de servicio a medida que crece su nivel transaccional. Aunque parezca un concepto claro, la escalabilidad de un sistema es un aspecto complejo e importante del diseño.

Existen dos enfoques principales, le escalabilidad vertical y la horizontal.

En el siguiente video te explicamos como funciona cada esquema de escalabilidad, los factores que influyen en su implementación y sus desafíos.

Los 7 mecanismos mas comunes para comunicar aplicaciones son:

• SOAP

• REST

• GraphQL

• gRPC

• Websocket

• Server Sent Events

• Publicador / Suscriptor

En esta entrada te explicamos cada uno, sus ventajas, desventajas y cuando usarlos.

Subscribe now

¿Qué es SACAViX?

En SACAViX llevamos varios años ayudando a los desarrolladores a crear mejor software, tenemos un blog de tecnología y un canal de Youtube en el que hablamos con cierta regularidad sobre microservicios, diseño de software y programación del lado del backend. Usamos Java & Spring.

1. ¿Qué gano suscribiéndome a este boletín?

Es una excelente pregunta 🙋

• Tendrás acceso directo a información de desarrollo de software en español.

• Hablamos de temas avanzados del desarrollo de software de forma simple, sin complicaciones.

• Te enviáremos un email cada semana (solo uno) con temas de microservicios, casos de estudio, diseño de software, Java, Spring o alguna otra novedad que nos resulte interesante.

• Te vas a mantener informado de los cursos y libros que vamos creando. Ya tenemos un libro que pronto daremos gratuitamente a nuestros suscriptores. Mantente alerta.

• Estamos escribiendo nuestro segundo libro sobre diseño e implementación de microservicios tolerantes a fallos, estar acá de dará un descuento especial de lanzamiento.

2. ¿ Qué puedo hacer para aprender mas ?

Lo primero, es suscribirte a este boletín , recomendarlo a amigos que le interesen estos temas y seguirnos en nuestro blog sacavix.com y en nuestro canal de Youtube.

3. Algunos materiales para empezar

Acá te dejo una lista de recursos que te recomiendo leer o ver que seguro te gustarán y de paso aprenderás algo nuevo 👀 .

1. Arquitectura limpia y hexagonal: Los principios y la esencia.

2. Video explicativo, en detalles sobre como implementar una arquitectura limpia con Spring framework.

3. Explicación con un ejemplo práctico del patron CQRS, uno de los patrones mas ampliamente usados para lograr la escalabilidad.

Bueno, te quiero dar la bienvenida a este substack, espero podamos aprender mucho juntos.