Architecture

The ME E2E service is a Go HTTP API built with the Fiber framework. It sits at the edge of the push notification sending chain and acts as a recording layer for end-to-end tests: the delivery service calls it after every push dispatch, and test suites query it to verify that correct notifications were sent to the right providers.

Overview

Delivery Service
      │
      │  POST /providers/:provider?save=true
      ▼
 ME E2E Service  ──► PostgreSQL (push_message)
      │
      │  GET /customers/:customerId/campaigns/:campaignId
      │  GET /customers/:customerId/campaigns/:campaignId/clients/:clientId
      ▼
 E2E Test Suites

The service has three independent binaries:

Binary Purpose

cmd/api

HTTP server — receives and serves notifications

cmd/migrate

Runs database migrations (executed as a pre-deploy hook)

cmd/maintenance

Periodic maintenance tasks (runs as a cron job every 10 minutes)

Endpoints

Public (no authentication)

Method Path Description

GET

/healthcheck

Returns { success: true }

GET

/healthcheckDependencies

Pings the database; returns success or failure

Escher Authenticated

Method Path Description

POST

/providers/:provider

Record a notification from a provider (?save=true to persist, ?save=false to discard)

POST

/save

Alternative endpoint for saving a notification from the request body

GET

/customers/:customerId/campaigns/:campaignId

List notifications for a campaign (paginated via $skip, $top, $count)

GET

/customers/:customerId/campaigns/:campaignId/clients/:clientId

List notifications for a specific client device

Supported provider names: apple, apns, google, huawei, vapid, fcm.

For the full API specification see REST API.

Database

The service uses PostgreSQL. Migrations are managed with goose and run via the cmd/migrate binary before each deployment.

The main table is push_message, which stores one row per recorded notification with fields including customer_id, campaign_id, hardware_id, provider, app_code, title, body, push_token, run_id, and original_payload.

Observability

  • OpenTelemetry: metrics are collected via an OTel sidecar and exported to Google Cloud Monitoring under the custom.googleapis.com prefix.

  • Logging: structured JSON logs, configurable via LOG_LEVEL.

  • Liveness / Readiness: both probes hit /healthcheck.

Deployment

The service is deployed via GAP on GKE:

  • Replicas: 2 (fixed)

  • CPU: requested 1 / limit 4

  • Memory: requested 512Mi / limit 1024Mi

  • Autoscaling target: CPU 30%

  • Service mesh: enabled

  • Pre-deploy: cmd/migrate runs database migrations

  • Cron: cmd/maintenance runs every 10 minutes