Fluxo de Dados do Sistema

🔄 Visão Geral do Fluxo de Dados

O Payment Gateway processa dados através de múltiplas camadas, garantindo integridade, segurança e rastreabilidade em todas as transações.

📊 Diagrama de Fluxo Principal

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   Client    │───►│ API Gateway │───►│   Payment   │───►│  Provider   │
│ Application │    │  Validation │    │   Service   │    │   Adapter   │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
       ▲                   ▲                   │                   │
       │                   │                   ▼                   ▼
┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  Webhook    │◄───│  Response   │◄───│  Database   │◄───│  External   │
│  Processor  │    │  Handler    │    │   Storage   │    │     API     │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘

🎯 Fluxos Detalhados

1. Fluxo de Criação de Pagamento

sequenceDiagram
    participant C as Client
    participant AG as API Gateway
    participant PS as Payment Service
    participant PA as Provider Adapter
    participant EP as External Provider
    participant DB as Database
    participant WH as Webhook

    C->>AG: POST /api/payments
    AG->>AG: Rate Limiting
    AG->>AG: Authentication
    AG->>PS: Process Payment
    PS->>PS: Validate Data
    PS->>PA: Select Provider
    PA->>EP: API Call
    EP->>PA: Response
    PA->>DB: Store Transaction
    DB->>PS: Confirmation
    PS->>AG: Success Response
    AG->>C: HTTP 201 Created
    EP->>WH: Webhook Notification
    WH->>DB: Update Status

2. Fluxo de Webhook Processing

sequenceDiagram
    participant EP as External Provider
    participant WH as Webhook Handler
    participant VS as Verification Service
    participant PS as Payment Service
    participant DB as Database
    participant NT as Notification

    EP->>WH: Webhook POST
    WH->>VS: Verify Signature
    VS->>WH: Signature Valid
    WH->>PS: Process Event
    PS->>DB: Update Payment Status
    DB->>PS: Update Confirmed
    PS->>NT: Trigger Notifications
    NT->>NT: Send Alerts
    WH->>EP: HTTP 200 OK

3. Fluxo de Dashboard Analytics

sequenceDiagram
    participant U as User
    participant D as Dashboard
    participant API as Analytics API
    participant DB as Database
    participant M as Metrics Store

    U->>D: Load Dashboard
    D->>API: GET /api/analytics
    API->>DB: Query Payments
    API->>M: Query Metrics
    DB->>API: Payment Data
    M->>API: Metrics Data
    API->>D: Aggregated Data
    D->>U: Render Charts

📋 Tipos de Dados Processados

1. Payment Data

{
  "id": "pay_12345",
  "amount": 100.00,
  "currency": "BRL",
  "method": "credit_card",
  "customer": {
    "email": "[email protected]",
    "name": "João Silva"
  },
  "metadata": {
    "order_id": "ORD-001",
    "source": "ecommerce"
  }
}

2. Transaction Data

{
  "id": "txn_67890",
  "payment_id": "pay_12345",
  "provider": "stripe",
  "provider_transaction_id": "pi_1234567890",
  "status": "succeeded",
  "amount": 100.00,
  "fees": 3.99,
  "net_amount": 96.01,
  "processed_at": "2024-01-15T10:30:00Z"
}

3. Webhook Event Data

{
  "id": "evt_abc123",
  "type": "payment.succeeded",
  "provider": "stripe",
  "data": {
    "payment_id": "pay_12345",
    "status": "succeeded",
    "amount": 100.00
  },
  "received_at": "2024-01-15T10:30:05Z"
}

🔐 Segurança no Fluxo de Dados

1. Criptografia em Trânsito

• TLS 1.3: Todas as comunicações externas

• mTLS: Comunicação entre serviços internos

• JWT: Tokens de autenticação assinados

2. Criptografia em Repouso

• AES-256: Dados sensíveis no banco

• Vault: Gerenciamento de secrets

• Tokenização: Dados de cartão de crédito

3. Validação e Sanitização

// Exemplo de validação de input
const paymentSchema = Joi.object({
  amount: Joi.number().positive().max(1000000).required(),
  currency: Joi.string().length(3).uppercase().required(),
  customer: Joi.object({
    email: Joi.string().email().required(),
    name: Joi.string().min(2).max(100).required()
  }).required()
});

📊 Transformação de Dados

1. Normalização de Providers

// Adapter pattern para uniformizar respostas
class ProviderAdapter {
  normalizeResponse(rawResponse) {
    return {
      id: this.extractId(rawResponse),
      status: this.mapStatus(rawResponse.status),
      amount: this.normalizeAmount(rawResponse.amount),
      currency: rawResponse.currency?.toUpperCase(),
      created_at: new Date(rawResponse.created_at).toISOString()
    };
  }
}

2. Agregação para Analytics

-- Query para dashboard analytics
SELECT 
  DATE(created_at) as date,
  COUNT(*) as total_payments,
  SUM(amount) as total_amount,
  AVG(amount) as average_amount,
  COUNT(CASE WHEN status = 'succeeded' THEN 1 END) as successful_payments
FROM payments 
WHERE created_at >= DATE('now', '-30 days')
GROUP BY DATE(created_at)
ORDER BY date DESC;

🔄 Fluxo de Estados

Payment Status Flow

created → processing → succeeded
   │           │           ▲
   ▼           ▼           │
failed    canceled    refunded

Transaction State Transitions

const VALID_TRANSITIONS = {
  'pending': ['processing', 'failed', 'canceled'],
  'processing': ['succeeded', 'failed'],
  'succeeded': ['refunded'],
  'failed': [],
  'canceled': [],
  'refunded': []
};

📈 Performance e Otimização

1. Caching Strategy

• Redis: Session data, temporary calculations

• Application Cache: Provider configurations

• Database Query Cache: Frequently accessed data

2. Batch Processing

// Batch webhook processing para alta carga
const batchSize = 100;
const webhookBatch = await WebhookQueue.dequeue(batchSize);
await Promise.allSettled(
  webhookBatch.map(webhook => processWebhook(webhook))
);

3. Database Optimization

• Indexes: On payment_id, merchant_id, status, created_at

• Partitioning: By date for large transaction tables

• Read Replicas: For analytics queries

🔍 Monitoring e Observabilidade

1. Data Flow Metrics

• Latency: P50, P95, P99 para cada stage

• Throughput: Requests per second por endpoint

• Error Rate: Por provider e método de pagamento

2. Business Metrics

• Conversion Rate: Successful payments / total attempts

• Revenue: Real-time and historical tracking

• Provider Performance: Success rate por provider

3. Alerting Rules

# Exemplo de regra Prometheus
- alert: HighPaymentFailureRate
  expr: rate(payment_failures_total[5m]) > 0.1
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: High payment failure rate detected

---

Última atualização: December 2024