ProyectoServerless Back-End
Cronograma en tiempo real de corte láser para varias máquinas
Tablero compartido en tiempo real para planificar el corte láser; reemplazó la programación manual en varias máquinas, 100 % serverless.
Stack
- AWS CDK
- TypeScript
- AWS Lambda
- API Gateway
- DynamoDB
- AWS Cognito
- S3
- IAM
- +17
01 · Cómo funciona
- HoyaModificado en este trabajo
- Flujo de datos
Qué hace
Un sistema de planificación que reemplazó la programación manual de trabajos de corte láser con un cronograma compartido en tiempo real que abarca varias máquinas, donde los planificadores arrastran los trabajos a su lugar y todos ven el mismo plan. Lo diseñé 100 % serverless: un cliente web en React con inicio de sesión gestionado, una API REST sobre funciones serverless, tablas NoSQL modeladas según las consultas de los planificadores, almacenamiento de archivos y una capa de analítica.
Leer más
Está definido como código y se despliega en entornos separados de desarrollo, staging y producción mediante un pipeline de CI/CD.
6 conexiones· elige un componente para ver su recorrido
- Cliente web planificador a Inicio de sesión: credenciales, renovar token
- Cliente web planificador a API REST: trabajos y cambios del plan
- API REST a Funciones serverless: solicitudes autorizadas
- Funciones serverless a Tablas NoSQL + índices: escrituras condicionalesmodificado
- Funciones serverless a Almacén de archivos: archivos de trabajos
- Tablas NoSQL + índices a Agregación analítica: historial de trabajos
02Qué logró
Resultado
- Planificación: programación manual → un cronograma compartido en tiempo real que abarca varias máquinas
- Integridad de datos: ediciones concurrentes protegidas con bloqueo optimista y escrituras condicionales
- Confiabilidad: 100 % de disponibilidad en producción, con auditoría
Leer más
- Escala y respuesta: 9 funciones serverless atendiendo 1,000+ solicitudes al día en menos de 200 ms
- Entrega: infraestructura como código con entornos separados de desarrollo, staging y producción
El desafío
Un plan compartido solo sirve si dos personas que lo editan a la vez no pueden corromperlo. Los cambios concurrentes sobre la misma línea de tiempo se pisaban entre sí, así que usé bloqueo optimista y escrituras condicionales: una edición obsoleta se rechaza en lugar de sobrescribir en silencio una más reciente.
La operación abarcaba dos regiones de la nube, lo que exigió diseñar patrones de acceso a datos y permisos que funcionaran en ambas.
Leer más
Además, un diseño serverless solo se mantiene rápido y barato si cada función se dimensiona de forma deliberada, así que la memoria, los tiempos de espera y los patrones de consulta se fijaron por función en lugar de dejarlos en sus valores por defecto. Todo tenía que ser reproducible, de modo que cada entorno nace del mismo código de infraestructura.
Qué aprendí
Modelar los datos alrededor de las preguntas que hace la gente: en un almacén NoSQL, las claves de partición y los índices secundarios tienen que salir de las consultas reales de los planificadores, porque añadirlos después resulta caro. Aplicar el mínimo privilegio es más fácil desde el primer día, así que cada función recibió solo los permisos que necesita.
Leer más
Definir toda la pila como código hizo reproducibles los entornos y rutinarios los rollbacks. Y la concurrencia pertenece a la capa de datos, no a la interfaz: las escrituras condicionales protegen el plan sin importar qué cliente envíe la edición.
Stack
- AWS CDK
- TypeScript
- AWS Lambda
- API Gateway
- DynamoDB
- AWS Cognito
- S3
- IAM
- CloudWatch
- Next.js
- React
- Material-UI
- Node.js
- Python
- AWS Amplify
- CodeCatalyst
- CloudFormation
- AWS SDK
- JWT
- CORS
- REST API
- NoSQL
- GSI
- Serverless Architecture
- Infrastructure as Code
Habilidades
- Arquitectura serverless
- Infraestructura como código
- Modelado de datos NoSQL
- Control de concurrencia
- Seguridad en la nube
