deploy-events

A small backend service that ingests and serves deployment event data, built in modern C++ (C++17). It seeds itself with mock deployments on startup and exposes a read API over them.

Requirements

• A C++17 compiler (g++ >= 9 or clang >= 10)
• CMake >= 3.16

Both dependencies — cpp-httplib and nlohmann/json — are single headers vendored in include/, so there is nothing to fetch or install.

Run it

cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j
./build/deploy-events

The server starts on http://localhost:8080 and prints how many deployments it seeded. Override the port with PORT=9000 ./build/deploy-events.

No CMake? A one-liner works too:

g++ -std=c++17 -O2 -Iinclude -Isrc src/main.cpp -o deploy-events -lpthread && ./deploy-events

Endpoints

GET /deployments

Lists deployments, newest first. Supported query parameters (all optional, combinable):

Param	Example	Notes
service	billing-api	exact match
status	success | failed | running	invalid values return 400
since	2025-06-01T00:00:00Z	ISO-8601 UTC, inclusive lower bound
until	2025-06-07T00:00:00Z	ISO-8601 UTC, exclusive upper bound

curl 'localhost:8080/deployments?service=billing-api&status=failed'

{
  "data": [
    {
      "id": "deploy_1004",
      "service": "billing-api",
      "status": "failed",
      "duration": 214,
      "timestamp": "2026-05-29T11:02:13Z",
      "commit_sha": "a1b2c3d"
    }
  ],
  "meta": {
    "count": 1,
    "filters": { "service": "billing-api", "status": "failed" }
  }
}

GET /deployments/:id

Returns a single deployment, or 404 if the id is unknown.

curl localhost:8080/deployments/deploy_1004

{ "data": { "id": "deploy_1004", "service": "billing-api", "...": "..." } }

GET /health

{ "status": "ok" }

Response shapes

Consistent across every endpoint:

• Success: { "data": ... } (list endpoints also include "meta")
• Error: { "error": { "code": "...", "message": "..." } }

Status codes used: 200, 400 (bad filter value), 404 (unknown id / route).

Smoke test

With the server running:

./scripts/smoke_test.sh

Layout

include/        vendored single-header deps (httplib.h, json.hpp)
src/
  models.hpp    Deployment struct, Status enum, JSON serialization
  store.hpp     DeploymentStore + DeploymentFilter (all data access)
  seed.hpp      deterministic mock-data generator
  main.cpp      HTTP routes, response envelope, error handling
scripts/
  smoke_test.sh

Design notes / tradeoffs

• Store is separated from the HTTP layer. Handlers never touch the underlying container; they go through DeploymentStore. New query shapes (aggregations, comparisons) become methods on the store rather than logic smeared across route handlers.
• The filter already carries a time window (since/until) even though only service/status were required. ISO-8601 strings sort lexicographically, so a window is just a string comparison, and anything that reasons about deployment frequency or recent behaviour will want it.
• Seed data is deterministic in shape, fresh in time. A fixed RNG seed keeps services/statuses/durations identical across runs (reproducible for reviewers), while timestamps are anchored to process start and spread over the prior 21 days, so time-window queries always have recent data. Each service has a baseline duration plus occasional slow outliers.
• In-memory store. Data lives in a vector plus an id index; fine for this scope. A real service would put this behind a persistence interface so the store could be swapped for SQLite/Postgres without touching handlers.
• Domain types are header-only for build simplicity at this size; I'd split them into translation units as the codebase grows.