Phase 04 — Product Operations

Deploy strategy, SLOs, DORA metrics, A/B experiments and monitoring.

Deploy Strategy

Environment v1

Local Development

ECP Pay v1 operates as a local service in the development ecosystem. Deploy is done via npm run dev with hot reload via tsx.

API Server: Fastify on port 3335
Admin Panel: Vite dev server on port 5176
Database: SQLite — database-pay.sqlite (auto-created)
Default provider: Internal (simulation mode)

Startup

# In project root
npm install
npm run dev

# Or separately
cd server && npm run dev  # API :3335
cd web && npm run dev     # Admin :5176

Data Seed

Database is automatically populated at startup with:

3 registered apps (ecp-bank, ecp-emps, ecp-food)
1 admin user (admin@ecpay.dev / Admin@123)
Default feature flags (PAYMENT_PROVIDER=internal)
Sample transactions for each type

Service Level Objectives (SLOs)

API Availability

99.9%

Uptime measured via GET /pay/health. Endpoint returns server status and active provider.

Webhook 1st Attempt Delivery

> 99%

Rate of callbacks delivered on first attempt. Measured via callback_status = delivered on first attempt.

API Latency (p95)

< 300ms

Latency at 95th percentile of payment endpoints, excluding external gateway latency.

DORA Metrics

Deployment Frequency

On-demand

Local on-demand deploy. Each change is reflected instantly via hot reload (tsx watch mode).

Lead Time for Changes

Minutes

Hot reload via tsx. Code changes are reflected in seconds on the development server.

Change Failure Rate

Tracked via audit_logs

All configuration changes and provider switches are recorded in the audit log for traceability.

Mean Time to Restore

Seconds

Server restart resolves most issues. Single-file SQLite does not require external database recovery.

Planned A/B Experiments

EXP-001 planned

Internal Mode Auto-Approve Delay

Hypothesis: Reducing the Pix auto-approve delay from 5s to 1s improves developer test cycle speed.

Metric: Time to complete a full payment test cycle.

Variants: 5s delay (control) vs. 1s delay (variant)

Linked KR: KR-04

EXP-002 planned

Transaction Timeline Granularity

Hypothesis: Adding elapsed time between steps in the timeline reduces investigation time for operators.

Metric: Time between opening transaction detail and identifying root cause.

Variants: Timestamps only (control) vs. Timestamps + elapsed (variant)

Linked KR: KR-05

EXP-003 planned

Provider Switch Confirmation Flow

Hypothesis: Adding impact preview (pending tx count) reduces accidental provider switches.

Metric: Accidental switch-backs within 5 minutes.

Variants: Simple confirmation (control) vs. Impact preview (variant)

Linked KR: KR-03

Monitoring Endpoints

GET/pay/health — Health check: server status, active provider, uptime

GET/admin/dashboard — KPIs: volume, transactions, success rate, tokens, pending webhooks

GET/admin/audit-logs — Audit log: all admin actions with filters

GET/admin/providers — Active provider status and configuration

GET/admin/feature-flags — Current feature flags and their values

operations-output.json