Overview
A serverless backend I built for the mobile app of a fiber-optic ISP. It does two jobs: manage the app’s contacts (a clean CRUD API) and deliver push and VoIP notifications to the device (APNs and Firebase). It’s a FastAPI service on AWS Lambda, with Cognito for authentication and a database for storage — I built the service end to end (the auth flow, the security model, and the notification setup), connecting it into the platform’s existing API Gateway and database cluster rather than standing those up myself.
The problem
The mobile app needed a backend for two essential jobs: a place to store and manage each user’s contacts, and a reliable way to reach the device with notifications — including high-priority VoIP pushes that wake the app even when it’s closed. That means real authentication, a security model that keeps one user’s data isolated from another’s, and the credential setup that push providers require.
What I built
- Authentication (Cognito) — the full flow on AWS Cognito: login, registration, email verification, password recovery, and refresh-token / logout, with JWT validation guarding the protected routes.
- Per-user security model — access rules so users can only reach their own data: identity is taken from the validated JWT rather than from client-supplied input, and write payloads can’t tamper with server-controlled fields.
- Contacts CRUD — create/read/update/delete for each user’s contacts, with search, pagination, and a soft-delete pattern.
- Push & VoIP notifications — this backend talks straight to APNs and Firebase/FCM, with no shared delivery layer in between: device-token registration (subscribe/unsubscribe), APNs VoIP pushes (the high-priority path that wakes a closed app), and FCM per-user and broadcast topics. I set up the provider side too, and kept those credentials in AWS Secrets Manager rather than in the image.
- Clean, layered API — each domain (auth, contacts, notifications) follows the same layered structure, with a dedicated error-mapping layer that turns provider and domain errors into consistent HTTP responses.
- Serverless setup — FastAPI on AWS Lambda behind the platform’s existing API Gateway, shipped by a GitHub Actions pipeline. The service’s own resources are declared in AWS CDK, and it stores its data in a new database created inside the existing shared cluster — I connected into that shared infrastructure rather than standing up the gateway or the cluster myself.
Architecture
It’s a thin, serverless service with a clear split of responsibilities: Cognito owns identity, a database holds the app’s own data (contacts, device tokens), and the APNs / Firebase channels carry notifications to the device. Keeping the credentials in Secrets Manager and identity in the JWT means the Lambda stays stateless and secure.
Impact
The hardest part of this project was the notification layer, and that’s where I focused: I got real VoIP pushes delivering end to end through APNs — the high-priority path that wakes the app even when it’s closed, and a fiddly integration to get right. I built and validated the whole service in a dev/test environment: auth, the per-user security model, contacts CRUD, and both push channels working together. It stands as a complete, self-contained backend design — identity in Cognito, secrets in Secrets Manager, app data in a database — a small, stateless surface to secure and operate.
