FraudGuard
Deploying and Operating a Fraud Scoring Service
FraudGuard is a real-time fraud detection service. The interesting work was not the prediction itself but everything around it: taking a scoring model and turning it into a service that starts reliably, answers over a stable HTTP contract, is covered by tests, and ships to a server without anyone running commands by hand.
Serving Layer
The scoring model sits behind a FastAPI application that owns request validation, the response schema, and error handling. Exposing it as a versioned REST endpoint means callers code against a stable contract rather than against the internals. Configuration is read from the environment for each deploy target, so the same image runs locally and on EC2 without host specific values baked in.
Tests and Tracking
pytest covers the request and response paths: valid payloads, malformed input, and the error responses the API is expected to return. The suite runs in CI on every push, so a change that breaks the contract fails before it reaches the server. MLflow is wired into the pipeline for run and artifact tracking, which keeps a record of what was produced and makes a given deploy traceable after the fact.
Build and Deploy Pipeline
The service is packaged as a Docker image so its runtime and dependencies are pinned rather than assumed. GitHub Actions builds that image, runs the test suite against it, and deploys to AWS EC2 on every push to the main branch. Deployment is therefore a normal part of committing rather than a separate manual step, and rolling forward is the same operation every time.
System Shape
A Vercel hosted frontend calls the live API over HTTP. Keeping the interface and the scoring service in separate deploy targets means the frontend can ship on its own cadence, and the service can be rebuilt or restarted without taking the interface down with it.
Key Features
What turns a prediction endpoint into a service that runs on its own
Versioned REST Endpoint
Scoring is exposed as a versioned FastAPI route, so the contract can change without breaking callers.
Containerized Service
The service and its dependencies are pinned in a Docker image, so local and EC2 runs stay identical.
Environment Driven Config
Settings come from the environment per deploy target, so no host specific values are baked into the image.
Request Path Test Suite
pytest covers the request and response paths, including malformed payloads and error handling.
Run and Artifact Tracking
MLflow is wired into the pipeline to record runs and store artifacts, keeping deploys traceable.
Push to Deploy Pipeline
GitHub Actions builds, tests, and deploys to AWS EC2 on every push to the main branch.
Separate Frontend
A Vercel hosted frontend calls the live API, keeping the interface and the service independently deployable.
Reproducible Rebuilds
The same pipeline runs on every commit, so a rebuild is routine rather than a manual operation.