Environments

Part of: MPAC SmartPOS Cloud Platform - Product RequirementsVersion: 2.0 Last Updated: 2026-01-28

---

Overview

This document defines the environment strategy for the MPAC SmartPOS Cloud Platform. The platform maintains four distinct environments, each serving a specific purpose in the software development lifecycle. The environment architecture ensures safe testing and validation before production deployment, with staging mirroring production at reduced scale and a disaster recovery environment ready for failover.

Table of Contents

• Environment Overview
• Staging Environment Details

---

Environment Overview

Purpose: Structured progression from development to production with appropriate testing and validation at each stage.

Environment Matrix

Environment	Purpose	Infrastructure	Access
Development	Local development	Docker Compose	Developers only
Staging	Pre-production testing	AWS (scaled down)	Developers, QA, Product
Production	Live system	AWS (full scale)	All users
DR (Disaster Recovery)	Backup region	AWS (standby)	Automatic failover

Development Environment

Purpose: Local development and unit testing.

Infrastructure:

• Orchestration: Docker Compose (mpac-smartpos/docker-compose.yml)
• Services:
  • PostgreSQL 15 (local container)
  • Redis 7 (local container)
  • All microservices (local ports)
• Data: Anonymized production data snapshots
• External Services: Mock providers or test accounts

Configuration:

# docker-compose.yml
version: "3.8"
services:
  postgres:
    image: postgres:15
    ports:
      - "5432:5432"
    environment:
      POSTGRES_DB: mpac_dev
      POSTGRES_USER: dev
      POSTGRES_PASSWORD: dev

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

  svc-portal:
    build: ./svc-portal
    ports:
      - "8002:8002"
    environment:
      DATABASE_URL: postgresql://dev:dev@postgres:5432/mpac_dev
      REDIS_URL: redis://redis:6379/0
      ENV: development

Usage:

# Start all services
cd mpac-smartpos
make up

# Start specific services
docker compose up postgres redis

# View logs
docker compose logs -f svc-portal

Benefits:

• Fast iteration cycles
• No cloud costs during development
• Full stack running locally
• Easy debugging with local tools

Staging Environment

Purpose: Pre-production testing and validation (see detailed section below).

Infrastructure: AWS (25% of production capacity)

Production Environment

Purpose: Live system serving all end users and devices.

Infrastructure:

• Region: AWS ap-northeast-1 (Tokyo)
• Compute:
  • ECS Fargate clusters
  • Auto-scaling: 50-500 tasks per service
• Database:
  • RDS PostgreSQL db.r6g.4xlarge
  • Multi-AZ with 2 read replicas
• Cache:
  • ElastiCache Redis cluster mode
  • 3 shards, 2 replicas per shard
• Load Balancing:
  • Application Load Balancer (ALB)
  • Network Load Balancer (NLB) for WebSocket

Scale:

• 400,000+ concurrent devices
• 80M transactions/day
• 15,000 RPS sustained at peak
• 99.95% uptime SLA

Access Control:

• Developers: Read-only access via AWS Console
• Operations: Full access via IAM roles
• All changes via CI/CD pipeline (no manual deployments)

Monitoring:

• CloudWatch dashboards
• Custom metrics and alarms
• PagerDuty integration for critical alerts
• Weekly capacity review meetings

DR (Disaster Recovery) Environment

Purpose: Backup region for business continuity during regional outages.

Infrastructure:

• Region: AWS ap-northeast-3 (Osaka)
• Compute: ECS Fargate (standby, minimal tasks)
• Database: RDS cross-region read replica (5-minute lag)
• Cache: ElastiCache Redis (empty, ready to sync)
• DNS: Route 53 failover routing policy

Failover Triggers:

• Primary region health check failure (3 consecutive failures)
• Manual failover command (disaster scenario)
• RTO (Recovery Time Objective): 15 minutes
• RPO (Recovery Point Objective): 5 minutes

Failover Process:

1. Detect primary region failure
2. Promote DR RDS read replica to primary
3. Update Route 53 DNS to point to DR region
4. Scale up DR ECS tasks to production capacity
5. Verify application health
6. Alert operations team

Cost Optimization:

• DR tasks run at minimum count (1 task per service)
• Scale up only during failover
• Monthly DR failover drills to validate readiness

---

Staging Environment Details

Purpose: Pre-production testing environment that mirrors production architecture at reduced scale.

Infrastructure Configuration

Compute:

• ECS Fargate: Same task definitions as production
• Task Count: 25% of production (10-50 tasks per service)
• Auto-scaling: Same policies, scaled down thresholds

Database:

• RDS PostgreSQL: db.r6g.xlarge (1/4 of production)
• Multi-AZ: Enabled
• Storage: 250GB (1/4 of production)
• Read Replicas: 1 (vs 2 in production)

Cache:

• ElastiCache Redis: cache.r6g.large
• Cluster Mode: Enabled (1 shard vs 3 in production)

Load Balancing:

• ALB: Same configuration as production
• Target Groups: Separate from production

Architecture Mirroring

Key Principle: Staging should behave identically to production, just at reduced scale.

Mirrored Components:

• Same VPC configuration (separate VPC)
• Same security groups and network ACLs
• Same IAM roles and policies
• Same environment variables structure
• Same container images (pre-production builds)

Differences from Production:

• Smaller instance sizes
• Fewer replicas/tasks
• Test payment provider accounts
• Synthetic test data
• Relaxed rate limits

Capacity

Scale: 25% of production capacity

Metric	Production	Staging
ECS Tasks	200-500 per service	50-125 per service
Database Size	db.r6g.4xlarge	db.r6g.xlarge
Redis Shards	3	1
Max Devices	400,000	100,000
Max RPS	15,000	3,750

Rationale:

• Sufficient for realistic load testing
• Cost-effective (1/4 of production costs)
• Can simulate peak loads with synthetic traffic

Real Payment Providers (Test Accounts)

Purpose: Test actual provider integrations without real money transactions.

Provider Test Accounts:

• PayPay: Test merchant account (sandbox mode)
• LINE Pay: Test merchant account (sandbox mode)
• Rakuten Pay: Test merchant account (sandbox mode)
• Credit Card Processor: Test merchant ID with test card numbers

Test Card Numbers:

Visa (Success): 4242 4242 4242 4242
Visa (Decline): 4000 0000 0000 0002
Mastercard (Success): 5555 5555 5555 4444
Amex (Success): 3782 822463 10005

QR Code Testing:

• Test QR codes generated by provider sandboxes
• Webhook events sent to staging URLs
• No real money movement

Benefits:

• Test real provider APIs
• Validate webhook handling
• Test error scenarios (declined payments, timeouts)
• Verify provider-specific edge cases

Synthetic Load Testing

Purpose: Validate system performance under realistic load conditions.

Load Testing Tools:

• k6: Load testing framework
• Locust: Python-based distributed load testing
• AWS CloudWatch Synthetics: Scheduled canary tests

Load Test Scenarios:

Scenario 1: Normal Load

Duration: 1 hour
VUs (Virtual Users): 1000
RPS: 500
Endpoints:
  - POST /v1/payments/create: 40%
  - GET /v1/bills: 30%
  - POST /v1/orders: 20%
  - GET /v1/devices: 10%

Scenario 2: Peak Load

Duration: 30 minutes
VUs: 2500
RPS: 3000
Ramp-up: 5 minutes
Sustained: 20 minutes
Ramp-down: 5 minutes

Scenario 3: Stress Test

Duration: 15 minutes
VUs: 5000
RPS: 5000+
Goal: Find breaking point
Expected: Graceful degradation, no data loss

Execution Schedule:

• Daily: Normal load test (automated)
• Weekly: Peak load test (automated)
• Pre-deployment: Full test suite (manual)
• Monthly: Stress test (manual)

Success Criteria:

Availability: > 99.9%
Error Rate: < 0.1%
Latency:
  P50: < 100ms
  P95: < 500ms
  P99: < 1000ms
Database:
  Connection Pool: < 80% utilization
  Query Time: < 50ms average

Automated Integration Tests

Purpose: Validate end-to-end workflows and service interactions.

Test Framework:

• Pytest: Python-based test framework
• Go Testing: Native Go test framework
• Postman/Newman: API testing

Test Categories:

1. API Integration Tests

# Example: Payment flow integration test
@pytest.mark.integration
async def test_payment_flow_e2e():
    # 1. Create order
    order = await create_order(merchant_id=1, store_id=1)
    assert order.status == "open"

    # 2. Create bill from order
    bill = await create_bill(order_id=order.id)
    assert bill.total_amount == order.total_amount

    # 3. Create payment intent
    payment_intent = await create_payment_intent(
        bill_id=bill.id,
        amount=bill.total_amount,
        method="credit_card"
    )
    assert payment_intent.status == "pending"

    # 4. Confirm payment (via provider sandbox)
    payment = await confirm_payment(payment_intent.id)
    assert payment.status == "completed"

    # 5. Verify bill is paid
    updated_bill = await get_bill(bill.id)
    assert updated_bill.status == "closed"

2. Service-to-Service Tests

@pytest.mark.integration
async def test_merchant_sync_svc_portal_to_pgw():
    # Create merchant in svc-portal
    merchant = await portal_api.create_merchant(
        name="Test Merchant",
        psp_id=1
    )

    # Wait for sync (should be < 5 seconds)
    await asyncio.sleep(5)

    # Verify merchant exists in mpac-pgw
    pgw_merchant = await pgw_api.get_merchant(merchant.id)
    assert pgw_merchant.merchant_id == merchant.id
    assert pgw_merchant.name == merchant.name

3. Authentication Flow Tests

@pytest.mark.integration
async def test_device_authentication_flow():
    # 1. Device registration
    device = await register_device(
        device_serial="TEST123456",
        merchant_id=1,
        store_id=1
    )

    # 2. Device JWT authentication
    jwt = await authenticate_device(
        device_uuid=device.device_uuid,
        private_key=device.private_key
    )
    assert jwt.expires_in == 120  # 2 minutes

    # 3. Use JWT to access protected endpoint
    orders = await get_orders(
        store_id=device.store_id,
        headers={"Authorization": f"Bearer {jwt.access_token}"}
    )
    assert isinstance(orders, list)

Execution Schedule:

• On Every Commit: Smoke tests (5 minutes)
• Before Deployment: Full integration test suite (30 minutes)
• Post-Deployment: Smoke tests on staging (5 minutes)
• Nightly: Extended test suite (2 hours)

CI/CD Integration:

# GitHub Actions workflow
jobs:
  integration-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Run Integration Tests
        run: |
          pytest tests/integration \
            --env=staging \
            --verbose \
            --junit-xml=report.xml

      - name: Publish Test Results
        if: always()
        uses: actions/upload-artifact@v2
        with:
          name: test-results
          path: report.xml

Test Data Management:

# Test data setup (before tests)
- Seed staging database with test merchants
- Create test device registrations
- Set up test payment provider configs
- Generate test transactions for reporting

# Test data cleanup (after tests)
- Delete test orders/bills older than 24h
- Preserve test merchants/devices for reuse
- Archive test results

---

Cross-References

Related Sections

• AWS Infrastructure - Infrastructure components for each environment
• Deployment Strategy - Deployment process across environments
• CI/CD Pipeline - Automated deployment to staging and production

Related Technical Sections

• Database Architecture - Database configuration per environment
• Security Architecture - Security controls per environment

---

Navigation

Previous: Deployment StrategyNext: CI/CD PipelineUp: Deployment Index