ProjectServerless Back-End
A live multi-machine timeline for laser cutting jobs
A shared, live planning board for laser cutting that replaced manual scheduling across several machines, serverless end to end.
Stack
- AWS CDK
- TypeScript
- AWS Lambda
- API Gateway
- DynamoDB
- AWS Cognito
- S3
- IAM
- +17
01 · How it works
- TodaytoChanged in this work
- Data flow
What it does
A planning system that replaced manual scheduling of laser cutting jobs with a live, shared timeline across several machines, where planners drag jobs into place and everyone sees the same plan. I designed it serverless end to end: a React web client with managed sign-in, a REST API on serverless functions, NoSQL tables modelled around the planners' queries, file storage and an analytics layer.
Read more
It is defined as code and deployed to separate development, staging and production environments through a CI/CD pipeline.
6 connections· select a part to trace it
- Planning web client to Sign-in service: credentials, token refresh
- Planning web client to REST API: jobs and timeline edits
- REST API to Serverless functions: authorized requests
- Serverless functions to NoSQL tables + indexes: conditional writeschanged
- Serverless functions to File storage: job files
- NoSQL tables + indexes to Analytics aggregation: job history
02What it achieved
Outcome
- Planning: manual scheduling → a live, shared timeline across several machines
- Data integrity: concurrent edits protected by optimistic locking and conditional writes
- Reliability: 100 % uptime in production, with auditing
Read more
- Scale and responsiveness: 9 serverless functions serving 1,000+ requests a day in under 200 ms
- Delivery: infrastructure as code with separate development, staging and production environments
The challenge
A shared plan is only useful if two people editing it at once cannot corrupt it. Concurrent changes to the same timeline raced each other, so I used optimistic locking and conditional writes: a stale edit is rejected instead of silently overwriting a newer one.
Operations spanned two cloud regions, which meant designing data access patterns and permissions that work across both.
Read more
A serverless design also stays fast and cheap only if each function is sized deliberately, so memory, timeouts and query patterns were set per function instead of left at defaults. All of it had to be reproducible, so every environment comes from the same infrastructure code.
What I learned
Model the data around the questions people ask: in a NoSQL store, partition keys and secondary indexes have to come from the planners' real queries, because retrofitting them later is expensive. Least privilege is easiest from day one, so every function got only the permissions it needs.
Read more
Defining the whole stack in code made environments reproducible and rollbacks routine. And concurrency belongs in the data layer, not in the interface: conditional writes protect the plan no matter which client sends the edit.
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
Skills
- Serverless architecture
- Infrastructure as code
- NoSQL data modelling
- Concurrency control
- Cloud security
