Diseño transaccional para sistema de venta de boletos
Visión general
De qué trata este proyecto.
Diseña el subsistema con 3 entidades centrales (Evento, Asiento, Reserva) y los siguientes flujos: reserva temporal (10 minutos), confirmación de compra, expiración automática. Justifica el nivel de aislamiento (Read Committed vs Repeatable Read vs Serializable) por flujo. Implementa con PostgreSQL 15 usando SELECT ... FOR UPDATE o filas advisory locks según corresponda. Escribe pruebas de concurrencia que simulen 200 compradores intentando reservar 50 asientos. Entrega el esquema, los procedimientos SQL, el harness de pruebas y un informe de 10 páginas con decisiones.
El Briefing
Lo que harás y lo que demostrarás.
Diseñar e implementar el subsistema transaccional de reserva y compra de asientos que garantice cero overbooking bajo concurrencia real, con pruebas demostrables.
Earning criteria — what you'll demonstrate
- Elegir nivel de aislamiento adecuado por flujo de negocio
- Implementar locks pesimistas vs optimistas según contexto
- Diseñar pruebas de concurrencia honestas y reproducibles
- Razonar sobre anomalías de aislamiento (lost update, write skew)
Encaje académico
Dónde encaja esto en tus estudios.
Afina las mismas habilidades que tu titulación espera de ti.
Habilidades
Habilidades que demostrarás.
Cada una aparece en tu credencial verificada.
Carreras
Roles para los que esto te prepara.
Títulos reales. Puentes de habilidades reales. Elige el que más se acerque a tu trayectoria.
Trayectorias profesionales que esto construye
Roles canónicosIngeniero/a Backend
Diseñar subsistemas transaccionales correctos bajo concurrencia es la prueba que distingue a personas backend que pueden trabajar en pagos, boletería o reservas.
Este proyecto afina
- transactions
- concurrency-control
- isolation-levels
Ingeniero/a de Software
Las personas ingenieras de software que entienden ACID en la práctica evitan los bugs más caros de su carrera.
Este proyecto afina
- transactions
- sql
- postgresql