DEV Community: fael

Migrando do RDS PostgreSQL para Aurora Serverless

fael — Thu, 20 Mar 2025 17:44:09 +0000

No cenário dinâmico das fintechs, a escalabilidade e a otimização de custos são desafios constantes. Recentemente, realizamos a migração do nosso banco de dados de um RDS PostgreSQL tradicional para o Aurora Serverless, e os benefícios foram significativos.

O Problema: Escalabilidade e Custos em um Ambiente Imprevisível

Nossa fintech lida com um volume de transações que pode variar drasticamente ao longo do dia. Em determinados momentos, o tráfego aumenta exponencialmente, exigindo mais recursos computacionais. No modelo tradicional do RDS PostgreSQL, enfrentávamos dois grandes desafios:

Capacidade Fixa ou Superdimensionamento: Precisávamos escolher entre manter uma instância com capacidade suficiente para os picos (o que gerava altos custos quando a carga era baixa) ou correr o risco de não suportar momentos de alta demanda.
Escalabilidade Manual: Mesmo com o recurso de escalabilidade do RDS, o ajuste de capacidade não era instantâneo, o que poderia impactar a performance durante os períodos de alta transação.
Alto Uso de CPU e Excesso de Conexões: Durante picos de tráfego, frequentemente atingíamos níveis elevados de uso de CPU, o que causava degradação do banco de dados. Além disso, a aplicação tentava abrir muitas conexões simultâneas para compensar a lentidão, sobrecarregando ainda mais o banco e, em alguns casos, levando-o a cair completamente.

Diante disso, buscamos uma solução que permitisse maior flexibilidade sem comprometer a confiabilidade do sistema.

A Solução: Aurora Serverless

O Aurora Serverless se destacou como a melhor opção por alguns motivos:

Escalabilidade Automática: Ele ajusta a capacidade automaticamente conforme a demanda, sem necessidade de intervenção manual.
Custo Proporcional ao Uso: Diferente do RDS tradicional, onde pagamos por instâncias ativas independentemente do uso, o Aurora Serverless cobra apenas pelos recursos efetivamente utilizados.
Alta Disponibilidade e Performance: Como parte do ecossistema AWS, ele mantém alta disponibilidade e replica automaticamente os dados para garantir resiliência.

O Processo de Migração

A migração envolveu algumas etapas essenciais:

Testes em Homologação: Subimos um banco Aurora Serverless em ambiente de homologação para realização de testes de carga, para entendermos se o problema seria resolvido, após esse teste tivemos a certeza que esse seria o melhor caminho.
Criação da Read Replica no Aurora: Durante o dia, configuramos uma read replica do RDS no Aurora para manter a sincronização contínua com a base original.
Fechamento do Security Group do RDS: Para garantir que não houvesse mais acessos à instância antiga, restringimos as conexões no Security Group do RDS.
Promoção da Read Replica para Master: Elevamos a read replica para a instância principal do banco no Aurora.
Ajuste do Endpoint: Atualizamos o endpoint do banco para apontar para a nova instância.
Provisionamento dos Novos Containers: Rodamos a pipeline para que a mudança fosse feita em todos os containers.

Os Resultados

Após a migração, observamos melhorias significativas:

✅ Redução de Custos: Conseguimos uma economia expressiva de mais de 70% no custo diário do banco de dados, graças ao modelo de cobrança baseado no uso real.
✅ Melhor Resiliência a Picos: A aplicação se tornou mais robusta e responsiva, suportando picos sem necessidade de intervenção manual.
✅ Menos Sobrecarga Operacional: Não precisamos mais ajustar a capacidade manualmente, permitindo que a equipe foque em outras melhorias.
✅ Transição Rápida e Segura: O processo de troca foi concluído em apenas 3 minutos de downtime, minimizando impactos para os usuários.

Conclusão

Para fintechs e outras empresas que lidam com demandas variáveis, o Aurora Serverless provou ser uma excelente escolha. A capacidade de escalar automaticamente e o modelo de custo baseado no uso real fazem toda a diferença em um ambiente onde previsibilidade é um desafio.

Pix

fael — Sun, 09 Feb 2025 20:06:57 +0000

Testes de Carga com K6

fael — Wed, 29 Jan 2025 13:28:53 +0000

Introdução

Testes de carga são essenciais para validar o desempenho de aplicações web e garantir que elas possam lidar com o tráfego esperado sem comprometer a experiência do usuário. O K6 é uma ferramenta poderosa, simples de usar e muito popular para realizar esse tipo de teste, permitindo simular milhares de usuários interagindo com sua aplicação de forma simultânea.

Por Que Realizar Testes de Carga?

Antes de mergulharmos na instalação e no uso do K6, é importante entender a importância dos testes de carga:
• Identificação de Gargalos de Desempenho: Encontrar pontos de falha antes que eles afetem seus usuários.
• Validação de Escalabilidade: Verificar se o sistema pode crescer sem comprometer a performance.
• Aperfeiçoamento de Recursos: Identificar quais recursos consomem mais CPU, memória ou tempo de resposta.
• Apoio ao Dimensionamento: Ajudar na escolha do tipo de infraestrutura necessária para sustentar a carga.

Instalação do K6

Para MacOS

Se você está usando MacOS, a maneira mais rápida de instalar o K6 é via Homebrew:

brew install k6

Para Linux

Se você usa Linux (Ubuntu, por exemplo), execute os seguintes comandos:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
echo "deb https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6

Para Windows

Se você utiliza Windows e possui o Chocolatey instalado, execute:

choco install k6

Executando um Teste de Carga Simples

Agora que o K6 está instalado, vamos configurar um teste simples de carga. Crie um arquivo chamado loadTest.js com o seguinte conteúdo:

import http from 'k6/http';
import { sleep } from 'k6';

export let options = {
  stages: [
    { duration: '1m', target: 100 }, // Sobe para 100 usuários em 1 minuto
    { duration: '5m', target: 100 }, // Mantém 100 usuários por 5 minutos
    { duration: '1m', target: 0 },   // Reduz para 0 usuários
  ],
};

export default function () {
  http.get('https://suaapi.com/endpoint');
  sleep(1);
}

Explicação do Código:
• stages: Define o comportamento de usuários ao longo do tempo. No exemplo, começamos com 0 usuários e aumentamos gradualmente até 100, mantendo esse número por 5 minutos antes de reduzir a 0 novamente.
• http.get: Realiza uma requisição GET ao endpoint da sua API.
• sleep(1): Pausa de 1 segundo entre as requisições, imitando o comportamento de usuários reais.

Para rodar o teste, use o seguinte comando:

k6 run loadTest.js

Analisando os Resultados

O K6 oferece uma saída detalhada no terminal após a execução do teste. Ela inclui informações como:
• Total de requisições realizadas.
• Taxa de sucesso ou falha das requisições.
• Tempo médio de resposta.
• Utilização de recursos (CPU, memória).

Cenários de Teste Avançados

Agora que você está familiarizado com um teste básico de carga, vamos explorar alguns cenários mais avançados:

Teste com Diversas URLs

Você pode testar múltiplos endpoints ao mesmo tempo para verificar como sua aplicação se comporta sob diferentes cargas:

export default function () {
  http.get('https://suaapi.com/endpoint1');
  http.get('https://suaapi.com/endpoint2');
  sleep(1);
}

Teste de Autenticação

Em muitos cenários, você precisa simular usuários autenticados. Para isso, você pode usar o Bearer Token ou cookies:

export default function () {
  let authHeaders = { headers: { Authorization: `Bearer ${TOKEN}` } };
  http.get('https://suaapi.com/endpoint', authHeaders);
  sleep(1);
}

Teste com Load Testing Variável

O K6 permite alterar dinamicamente o número de usuários de acordo com a situação, o que é útil para simulações mais realistas. Um exemplo disso seria um cenário de pico de tráfego.

export let options = {
  stages: [
    { duration: '1m', target: 50 },   // Aumenta para 50 usuários rapidamente
    { duration: '10m', target: 500 }, // Aumenta para 500 usuários por 10 minutos
    { duration: '1m', target: 0 },    // Reduz para 0 rapidamente
  ],
};

Dicas de Boas Práticas
• Simule Cenários Reais: Evite usar números irrealistas de usuários. Um tráfego realista traz resultados mais confiáveis.
• Mantenha o Monitoramento: Testes de carga podem sobrecarregar sua infraestrutura, então, é importante monitorar os servidores enquanto os testes estão sendo executados.
• Automatize os Testes: Execute testes de carga periodicamente para garantir que sua aplicação continue performando bem conforme o crescimento do tráfego.
• Ajuste as Configurações de stages: Use diferentes fases para simular o comportamento real dos usuários.

Conclusão

O K6 é uma ferramenta robusta e de fácil implementação para realizar testes de carga. Ela ajuda a identificar problemas de desempenho antes que eles se tornem um problema real para os usuários. Ao simular tráfego realista e coletar dados precisos, você pode otimizar sua aplicação e garantir que ela seja capaz de lidar com grandes volumes de acessos simultâneos.

ACID Transactions em uma Aplicação Fintech:

fael — Wed, 29 Jan 2025 13:11:46 +0000

Introdução

Em aplicações de fintech, garantir a integridade das transações financeiras é essencial. Problemas como transações incompletas ou dados inconsistentes podem comprometer a confiança dos usuários e a segurança do sistema. Para mitigar esses riscos, podemos usar os conceitos de transações ACID, que garantem operações confiáveis e robustas.

Neste artigo, vou mostrar as propriedades ACID e uma implementação usando NestJS, Prisma e PostgreSQL, utilizando o seguinte modelo de transação:

model Transaction {
  id                Int      @id @default(autoincrement())
  userId            Int
  subTotal          Decimal  @default(0) @db.Decimal(10, 2)
  total             Decimal  @default(0) @db.Decimal(10, 2)
  transactionId     String?  @unique
  order_processor_id String
  payment_method    PaymentMethod
  status            TransactionStatus
  external_id       String
  e2e_id            String?
  error_message     String?
  created_at        DateTime? @default(now())
  updated_at        DateTime? @updatedAt
  customerId        Int?
  callback_url      String?
  typeTransaction   TypeTransaction
  future_balance    Decimal  @default(0) @db.Decimal(10, 2)
  previous_balance  Decimal  @default(0) @db.Decimal(10, 2)

  Customers         Customer? @relation(fields: [customerId], references: [id])
  user              User      @relation(fields: [userId], references: [id])
}

Entendendo as Propriedades ACID

1. Atomicidade (Atomicity)

A atomicidade garante que uma transação seja tratada como uma unidade indivisível. Ou todas as operações dentro da transação são executadas com sucesso, ou nenhuma é aplicada. Isso é crucial em aplicações fintech para evitar cenários como debitar uma conta sem creditar o destinatário.

Exemplo:
Imagine transferir fundos entre duas contas:

await this.prisma.$transaction(async (prisma) => {
  await prisma.transaction.create({
    data: {
      userId: fromUserId,
      subTotal: amount,
      total: amount,
      status: 'PENDING',
    },
  });

  await prisma.transaction.create({
    data: {
      userId: toUserId,
      subTotal: amount,
      total: amount,
      status: 'COMPLETED',
    },
  });
});

Se a criação de qualquer uma das transações falhar, o sistema garante que nenhuma alteração seja persistida.

2. Consistência (Consistency)

A consistência assegura que o banco de dados transite de um estado válido para outro, sempre preservando regras e restrições definidas.

Exemplo:
Ao criar uma nova transação, todos os campos obrigatórios, como userId, subTotal e status, devem ser válidos.

model Transaction {
  id         Int      @id @default(autoincrement())
  userId     Int
  subTotal   Decimal  @default(0) @db.Decimal(10, 2)
  total      Decimal  @default(0) @db.Decimal(10, 2)
  status     String
}

Se qualquer campo obrigatório estiver ausente ou contiver dados inválidos, o banco de dados rejeita a transação, mantendo a consistência.

3. Isolamento (Isolation)

O isolamento garante que transações concorrentes não interfiram umas com as outras. Cada transação é executada como se fosse a única operando no sistema.

Exemplo:
Se dois usuários iniciam transações simultaneamente, a propriedade de isolamento garante que os cálculos de saldo permaneçam precisos.

await this.prisma.$transaction([operation1, operation2]);

O PostgreSQL lida com diferentes níveis de isolamento (READ COMMITTED, SERIALIZABLE, etc.) para gerenciar operações concorrentes.

4. Durabilidade (Durability)

A durabilidade garante que, uma vez que uma transação é confirmada, ela permanece persistente, mesmo em caso de falha do sistema.

Exemplo:
Após registrar com sucesso uma transação financeira, os dados permanecem intactos e disponíveis, independentemente de falhas no servidor.

await this.prisma.transaction.create({
  data: {
    userId: userId,
    subTotal: amount,
    total: amount,
    status: 'PROCESSED',
  },
});

Uma vez confirmada, o PostgreSQL garante que a transação persista no disco.

Conclusão

As transações ACID são essenciais para garantir a confiabilidade e integridade das operações financeiras em aplicações fintech. Compreender e implementar corretamente as propriedades de Atomicidade, Consistência, Isolamento e Durabilidade é fundamental para construir serviços financeiros seguros e escaláveis.

Ensuring Data Integrity in Financial Transactions: The PostgreSQL Transaction Solution

fael — Mon, 25 Nov 2024 17:19:26 +0000

When it comes to financial systems, data integrity is one of the most crucial concerns. In a financial transaction environment, failures can result in loss of money, inconsistency in account balances, or even security breaches. To ensure that data remains consistent and secure, the use of transactions in the database is essential. In this article, we will explore how transactions in PostgreSQL help solve these problems, with practical examples using NestJS and Prisma to implement robust solutions.

What Are Banking Transactions?

In a banking context, a transaction usually involves moving money between accounts or updating balances. The atomicity of a transaction is essential to ensure that all necessary steps to complete the operation are successfully carried out, and that if an error occurs at any stage, the entire process is rolled back to prevent inconsistencies.

For example, when transferring money from one account to another, the transaction involves:

Subtracting the amount from the source account.
Adding the amount to the destination account.

If any of these steps fail, such as a network failure or system error, the balance of one account may be updated without the other, leading to inconsistent data. Transactions are used to ensure that both actions occur, or neither, maintaining data integrity.

The Solution: Transactions in PostgreSQL

PostgreSQL is a relational database that natively supports transactions, ensuring that database operations are atomic, consistent, isolated, and durable — characteristics known by the acronym ACID (Atomicity, Consistency, Isolation, and Durability). Using transactions, we can guarantee that all steps of a banking operation are successfully completed or, in case of an error, rolled back.

How Does a Transaction Work in PostgreSQL?

In simple terms, a transaction in PostgreSQL starts with the BEGIN statement and ends with COMMIT. If any error occurs during the transaction, the ROLLBACK command is called to undo all changes made up to that point. Here is a basic example of a transaction in PostgreSQL:

BEGIN;

UPDATE accounts SET balance = balance - 100 WHERE id = 1; -- Subtract 100 from the source account
UPDATE accounts SET balance = balance + 100 WHERE id = 2; -- Add 100 to the destination account

COMMIT; -- If everything goes well, confirm the changes

If something goes wrong, like the source account not having sufficient funds or a database failure, a ROLLBACK can be triggered to ensure that none of the changes are applied.

Practical Example Using NestJS and Prisma

Now that we understand the concept of transactions, let’s integrate this with NestJS and Prisma.

Configuring Prisma with PostgreSQL

First, let's configure Prisma to work with PostgreSQL in your NestJS project. Make sure that Prisma is set up correctly in your project.

Install Prisma and dependencies:

npm install @prisma/client
npm install prisma --save-dev

Configure Prisma (in the prisma/schema.prisma file):

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model Account {
  id     Int       @id @default(autoincrement())
  balance Decimal   @default(0) @db.Decimal(10, 2)
}

Run the migration to apply the changes to the database:

npx prisma migrate dev --name init

Implementing Transactions in NestJS with Prisma

In NestJS, we can use Prisma to manage transactions within services. Let’s create a service that simulates transferring funds between accounts. We will use the prisma.$transaction method to ensure the transfer is atomic.

Service Code

import { Injectable } from '@nestjs/common';
import { PrismaService } from './prisma.service'; // Prisma service
import { Prisma } from '@prisma/client';

@Injectable()
export class TransactionsService {
  constructor(private prisma: PrismaService) {}

  async transferFunds(sourceAccountId: number, destinationAccountId: number, amount: number) {
    const sourceAccount = await this.prisma.account.findUnique({ where: { id: sourceAccountId } });
    const destinationAccount = await this.prisma.account.findUnique({ where: { id: destinationAccountId } });

    if (!sourceAccount || !destinationAccount) {
      throw new Error('Account not found');
    }

    if (sourceAccount.balance < amount) {
      throw new Error('Insufficient balance');
    }

    // Starting the transaction
    return this.prisma.$transaction(async (prisma) => {
      // Subtract from the source account
      await prisma.account.update({
        where: { id: sourceAccountId },
        data: { balance: sourceAccount.balance - amount },
      });

      // Add to the destination account
      await prisma.account.update({
        where: { id: destinationAccountId },
        data: { balance: destinationAccount.balance + amount },
      });
    });
  }
}

Code Explanation:

prisma.$transaction: This method is used to wrap database operations within a transaction. If any part of the transaction fails, all changes made within the transaction are automatically rolled back.
Validation: Before starting the transaction, we validate that the accounts exist and that there is sufficient balance in the source account.
Atomic operations: We use prisma.account.update to update the balances of the accounts. Both the subtraction and addition operations happen within the same transaction, ensuring that both occur successfully or that neither occurs if an error happens.

Benefits of Transactions for Banking Systems

By using transactions in PostgreSQL, we ensure:

Atomicity: If something goes wrong, such as insufficient balance or a database error, the entire transaction is rolled back, and no changes are persisted.
Consistency: After the transaction, the database will be in a consistent state, without incorrect balances or duplicated data.
Isolation: Transactions are isolated from each other, meaning concurrent transactions do not interfere with each other.
Durability: Once the transaction is confirmed with COMMIT, the data is guaranteed to be persistent, even in the event of a system failure.

Final Considerations

Using transactions in PostgreSQL is essential to ensure data integrity in financial systems. Transactions ensure that critical operations, such as fund transfers, are performed atomically and securely.

By adopting appropriate transactions and following good data handling practices, we can minimize risks, such as data loss and inconsistencies, providing a secure and reliable experience for users of the banking system.

Garantindo a Integridade de Dados em Transações Financeiras: A Solução com Transações no PostgreSQL

fael — Mon, 25 Nov 2024 17:17:35 +0000

Quando se trata de sistemas financeiros, a integridade de dados é uma das preocupações mais cruciais. Em um ambiente de transações financeiras, falhas podem resultar em perda de dinheiro, inconsistência no saldo das contas ou até mesmo falhas de segurança. Para garantir que os dados permaneçam consistentes e seguros, o uso de transações no banco de dados é fundamental. Neste artigo, vamos explorar como as transações no PostgreSQL ajudam a resolver esses problemas, com exemplos práticos usando NestJS e Prisma para implementar soluções robustas.

O Que São Transações Bancárias?

Em um contexto bancário, uma transação geralmente envolve a movimentação de dinheiro entre contas ou a atualização de saldos. A atomicidade de uma transação é essencial para garantir que todos os passos necessários para completar a operação sejam realizados com sucesso, e que, caso ocorra algum erro em qualquer etapa, todo o processo seja revertido para evitar inconsistências.

Por exemplo, ao transferir dinheiro de uma conta para outra, a transação envolve:

Subtrair o valor da conta de origem.
Adicionar o valor à conta de destino.

Se uma dessas etapas falhar, como uma falha de rede ou erro de sistema, o saldo de uma conta pode ser atualizado sem a outra, levando a dados inconsistentes. Transações são usadas para garantir que ambas as ações ocorram ou nenhuma delas, mantendo a integridade dos dados.

A Solução: Transações no PostgreSQL

O PostgreSQL é um banco de dados relacional que suporta transações de forma nativa, garantindo que operações de banco de dados sejam atômicas, consistentes, isoladas e duráveis — características conhecidas pela sigla ACID (Atomicidade, Consistência, Isolamento e Durabilidade). Usando transações, podemos garantir que todas as etapas de uma operação bancária sejam concluídas com sucesso ou, em caso de erro, revertidas.

Como Funciona uma Transação no PostgreSQL?

Em termos simples, uma transação no PostgreSQL começa com a instrução BEGIN e termina com COMMIT. Se algum erro ocorrer durante a transação, o comando ROLLBACK é chamado para reverter todas as alterações feitas até aquele ponto. Aqui está um exemplo básico de uma transação SQL no PostgreSQL:

BEGIN;

UPDATE contas SET saldo = saldo - 100 WHERE id = 1; -- Subtrai 100 da conta de origem
UPDATE contas SET saldo = saldo + 100 WHERE id = 2; -- Adiciona 100 na conta de destino

COMMIT; -- Se tudo ocorrer bem, confirma as alterações

Se algo der errado, como a conta de origem não ter saldo suficiente ou uma falha no banco de dados, um ROLLBACK pode ser acionado para garantir que nenhuma das alterações seja aplicada.

Exemplo Prático Usando NestJS e Prisma

Agora que entendemos o conceito de transações, vamos integrar isso com NestJS e Prisma.

Configuração do Prisma com PostgreSQL

Primeiro, vamos configurar o Prisma para trabalhar com PostgreSQL no seu projeto NestJS. Certifique-se de que o Prisma está configurado corretamente no seu projeto.

Instale o Prisma e as dependências:

npm install @prisma/client
npm install prisma --save-dev

Configure o Prisma (no arquivo prisma/schema.prisma):

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model Conta {
  id     Int       @id @default(autoincrement())
  saldo  Decimal   @default(0) @db.Decimal(10, 2)
}

Execute a migração para aplicar as mudanças no banco de dados:

npx prisma migrate dev --name init

Implementando Transações no NestJS com Prisma

No NestJS, podemos usar o Prisma para gerenciar transações dentro dos serviços. Vamos criar um serviço que simula a transferência de fundos entre contas. Usaremos o método prisma.$transaction para garantir que a transferência seja atômica.

Código do Serviço

import { Injectable } from '@nestjs/common';
import { PrismaService } from './prisma.service'; // Serviço Prisma
import { Prisma } from '@prisma/client';

@Injectable()
export class TransacoesService {
  constructor(private prisma: PrismaService) {}

  async transferirFundos(contaOrigemId: number, contaDestinoId: number, valor: number) {
    const contaOrigem = await this.prisma.conta.findUnique({ where: { id: contaOrigemId } });
    const contaDestino = await this.prisma.conta.findUnique({ where: { id: contaDestinoId } });

    if (!contaOrigem || !contaDestino) {
      throw new Error('Conta não encontrada');
    }

    if (contaOrigem.saldo < valor) {
      throw new Error('Saldo insuficiente');
    }

    // Iniciando a transação
    return this.prisma.$transaction(async (prisma) => {
      // Subtrai da conta de origem
      await prisma.conta.update({
        where: { id: contaOrigemId },
        data: { saldo: contaOrigem.saldo - valor },
      });

      // Adiciona na conta de destino
      await prisma.conta.update({
        where: { id: contaDestinoId },
        data: { saldo: contaDestino.saldo + valor },
      });
    });
  }
}

Explicação do Código:

prisma.$transaction: Este método é usado para envolver as operações de banco de dados dentro de uma transação. Se qualquer parte da transação falhar, todas as alterações feitas dentro da transação serão revertidas automaticamente.
Validação: Antes de iniciar a transação, validamos se as contas existem e se há saldo suficiente na conta de origem.
Operações atômicas: Usamos o prisma.conta.update para atualizar os saldos das contas. Ambas as operações de subtração e adição de saldo acontecem dentro da mesma transação, garantindo que ambas ocorram com sucesso ou que nenhuma delas aconteça se um erro ocorrer.

Benefícios das Transações para Sistemas Bancários

Ao usar transações no PostgreSQL, garantimos:

Atomicidade: Se algo der errado, como saldo insuficiente ou erro de banco de dados, a transação inteira será revertida e nenhuma alteração será persistida.
Consistência: Após a transação, o banco de dados estará em um estado consistente, sem saldo incorreto ou dados duplicados.
Isolamento: As transações são isoladas umas das outras, o que significa que transações concorrentes não interferem umas nas outras.
Durabilidade: Uma vez que a transação é confirmada com COMMIT, os dados são garantidos como persistentes, mesmo em caso de falha de sistema.

Considerações Finais

O uso de transações no PostgreSQL é essencial para garantir a integridade de dados em sistemas financeiros. Transações asseguram que operações críticas, como transferências de fundos, sejam realizadas de forma atômica e segura.

Ao adotar transações adequadas e seguir boas práticas de manipulação de dados, é possível minimizar riscos, como perda de dados e inconsistências, oferecendo uma experiência segura e confiável para os usuários do sistema bancário.

Aplicando SOLID no NestJS

fael — Fri, 08 Nov 2024 20:15:36 +0000

Introdução

O NestJS é um framework progressivo para construir aplicações back-end em Node.js que facilita a criação de APIs escaláveis e modulares. Um dos conceitos fundamentais para manter uma base de código limpa e sustentável em projetos NestJS é seguir os princípios SOLID.

Os princípios SOLID formam uma base sólida para o design orientado a objetos, ajudando a tornar o código mais legível, fácil de manter e escalável. Neste artigo, vamos revisar cada um desses princípios (SRP, OCP, LSP, ISP e DIP) e explorar como aplicá-los com exemplos práticos no NestJS.

Princípio da Responsabilidade Única (SRP)

O Princípio da Responsabilidade Única (Single Responsibility Principle) afirma que uma classe deve ter apenas uma razão para mudar, ou seja, uma única responsabilidade. No contexto de NestJS, isso significa manter o foco de cada serviço, controlador ou repositório em uma função específica.

Exemplo de Aplicação SRP no NestJS

Imagine que temos uma aplicação com funcionalidades de usuários e autenticação. Ao invés de ter um único UserService para gerenciar tanto as informações dos usuários quanto a autenticação, podemos dividir essas responsabilidades em serviços separados:

// src/user/user.service.ts
import { Injectable } from '@nestjs/common';

@Injectable()
export class UserService {
  // Funções relacionadas à manipulação de dados do usuário
  async createUser(data: CreateUserDto) { /*...*/ }
  async getUserById(id: string) { /*...*/ }
}

// src/auth/auth.service.ts
import { Injectable } from '@nestjs/common';

@Injectable()
export class AuthService {
  // Funções relacionadas à autenticação
  async login(credentials: LoginDto) { /*...*/ }
  async validateUser(token: string) { /*...*/ }
}

Dividir os serviços dessa forma facilita a manutenção e evita que mudanças em uma funcionalidade afetem outra.

Princípio Aberto/Fechado (OCP)

O Princípio Aberto/Fechado (Open/Closed Principle) afirma que classes, módulos e funções devem estar abertos para extensão, mas fechados para modificação. Isso significa que devemos ser capazes de adicionar novos comportamentos ao sistema sem modificar o código existente.

Exemplo de Aplicação OCP no NestJS

Suponha que temos uma funcionalidade de envio de notificações. Se quisermos suportar diferentes canais de notificação (por exemplo, e-mail e SMS), podemos criar uma interface NotificationService e implementar classes específicas para cada tipo de notificação.

// src/notification/interfaces/notification.interface.ts
export interface NotificationService {
  sendNotification(message: string): Promise<void>;
}

// src/notification/services/email-notification.service.ts
import { Injectable } from '@nestjs/common';
import { NotificationService } from '../interfaces/notification.interface';

@Injectable()
export class EmailNotificationService implements NotificationService {
  async sendNotification(message: string): Promise<void> {
    console.log('Enviando notificação por email:', message);
  }
}

// src/notification/services/sms-notification.service.ts
import { Injectable } from '@nestjs/common';
import { NotificationService } from '../interfaces/notification.interface';

@Injectable()
export class SmsNotificationService implements NotificationService {
  async sendNotification(message: string): Promise<void> {
    console.log('Enviando notificação por SMS:', message);
  }
}

Com essa abordagem, podemos adicionar novos canais de notificação sem modificar o código existente, apenas criando novas implementações da interface NotificationService.

Princípio da Substituição de Liskov (LSP)

O Princípio da Substituição de Liskov (Liskov Substitution Principle) declara que as subclasses devem ser substituíveis por suas superclasses sem alterar a funcionalidade do programa. No NestJS, ao usar injeção de dependência, precisamos garantir que as implementações injetadas cumpram o contrato da interface.

Exemplo de Aplicação LSP no NestJS

No exemplo de notificação, garantimos que qualquer implementação de NotificationService (EmailNotificationService, SmsNotificationService, etc.) pode substituir a outra sem mudar o comportamento esperado do código:

// src/notification/notification.controller.ts
import { Controller, Inject } from '@nestjs/common';
import { NotificationService } from './interfaces/notification.interface';

@Controller('notification')
export class NotificationController {
  constructor(
    @Inject('NotificationService') private readonly notificationService: NotificationService,
  ) {}

  sendMessage(message: string) {
    this.notificationService.sendNotification(message);
  }
}

O controlador NotificationController pode trabalhar com qualquer implementação de NotificationService, mantendo a conformidade com o princípio LSP.

Princípio da Segregação de Interface (ISP)

O Princípio da Segregação de Interface (Interface Segregation Principle) afirma que uma classe não deve ser obrigada a implementar interfaces que não usa. No NestJS, esse princípio pode ser aplicado ao criar interfaces menores e mais específicas para cada responsabilidade.

Exemplo de Aplicação ISP no NestJS

Em vez de criar uma interface grande para gerenciar todas as operações de um serviço, separamos as interfaces em responsabilidades menores. Por exemplo, para um serviço de repositório de dados:

// src/repository/interfaces/read.interface.ts
export interface Read<T> {
  findAll(): Promise<T[]>;
  findOne(id: string): Promise<T>;
}

// src/repository/interfaces/write.interface.ts
export interface Write<T> {
  create(item: T): Promise<T>;
  update(id: string, item: T): Promise<T>;
  delete(id: string): Promise<void>;
}

// src/repository/interfaces/repository.interface.ts
import { Read } from './read.interface';
import { Write } from './write.interface';

export interface Repository<T> extends Read<T>, Write<T> {}

As classes podem implementar apenas as interfaces que realmente precisam, evitando métodos não utilizados.

Princípio da Inversão de Dependência (DIP)

O Princípio da Inversão de Dependência (Dependency Inversion Principle) declara que módulos de alto nível não devem depender de módulos de baixo nível, mas ambos devem depender de abstrações. Em NestJS, podemos aplicar DIP usando injeção de dependência e interfaces.

Exemplo de Aplicação DIP no NestJS

No exemplo abaixo, o controlador depende da interface NotificationService ao invés de uma implementação específica:

// src/notification/notification.module.ts
import { Module } from '@nestjs/common';
import { NotificationController } from './notification.controller';
import { EmailNotificationService } from './services/email-notification.service';

@Module({
  controllers: [NotificationController],
  providers: [
    { provide: 'NotificationService', useClass: EmailNotificationService },
  ],
})
export class NotificationModule {}

Dessa forma, podemos alterar a implementação de NotificationService sem modificar NotificationController, respeitando o princípio de inversão de dependência.

Conclusão

Aplicar os princípios SOLID no NestJS ajuda a criar uma arquitetura mais robusta, modular e fácil de manter. Seguir esses princípios exige disciplina e planejamento, mas, a longo prazo, traz benefícios significativos para a qualidade e a escalabilidade do código. Ao desenvolver um projeto NestJS, mantenha os princípios SOLID em mente para estruturar um código limpo e sustentável.

Explorando Notificações Push no React Native com Expo e OneSignal!

fael — Thu, 07 Nov 2024 12:55:35 +0000

Ótimo! Aqui está a estrutura do artigo, incluindo os trechos de código que você compartilhou. Isso deve facilitar para os leitores a configuração e integração do OneSignal em um aplicativo Expo.

Configurando Notificações Push no Expo com OneSignal

Neste guia, vamos configurar o OneSignal para enviar notificações push no seu aplicativo Expo. Com as notificações push, você pode melhorar a interação com seus usuários, mantendo-os informados com atualizações em tempo real.

Pré-requisitos

Conta no OneSignal.
SDK do Expo CLI configurado.
Projeto criado no Expo.

Instalar as dependencias:

npx expo install react-native-onesignal

npx expo install onesignal-expo-plugin

Passo 1: Configurando o `app.json` com o OneSignal

Primeiro, vamos configurar o app.json do projeto Expo para incluir o plugin do OneSignal. Aqui está a estrutura do arquivo app.json:

{
  "expo": {
    "name": "notification-app",
    "slug": "notification-app",
    "version": "1.0.0",
    "orientation": "portrait",
    "icon": "./src/assets/images/icon.png",
    "scheme": "myapp",
    "userInterfaceStyle": "automatic",
    "splash": {
      "image": "./src/assets/images/splash.png",
      "resizeMode": "contain",
      "backgroundColor": "#ffffff"
    },
    "assetBundlePatterns": ["**/*"],
    "ios": {
      "supportsTablet": true,
      "bundleIdentifier": "com.notification-app"
    },
    "android": {
      "adaptiveIcon": {
        "foregroundImage": "./src/assets/images/adaptive-icon.png",
        "backgroundColor": "#ffffff"
      }
    },
    "web": {
      "bundler": "metro",
      "output": "static",
      "favicon": "./src/assets/images/favicon.png"
    },
    "plugins": [
      "expo-router",
      [
        "onesignal-expo-plugin",
        {
          "mode": "development"
        }
      ]
    ],
    "experiments": {
      "typedRoutes": true
    }
  }
}

Observação: Altere "YOUR_ONESIGNAL_APP_ID" para o ID do seu app no OneSignal.

Passo 2: Inicializando o OneSignal no Projeto

Vamos criar um arquivo OneSignalEntry.ts para organizar a inicialização do OneSignal.

import OneSignal from 'react-native-onesignal';

export function OneSignalEntry(): void {
  // Inicializando o OneSignal
  OneSignal.setLogLevel(6, 0);
  OneSignal.setAppId('XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX');

  // Solicita permissão para notificações no iOS
  OneSignal.promptForPushNotificationsWithUserResponse(() => {});

  // Gerencia notificações recebidas com o app em primeiro plano
  OneSignal.setNotificationWillShowInForegroundHandler((notificationReceivedEvent) => {
    const notification = notificationReceivedEvent.getNotification();
    const data = notification.additionalData;

    notificationReceivedEvent.complete(notification);
  });

  // Gerencia notificações abertas
  OneSignal.setNotificationOpenedHandler((notification) => {});
}

Esse código define como o OneSignal deve se comportar quando uma notificação é recebida ou aberta, além de solicitar a permissão para notificações push no iOS.

Passo 3: Integração no Componente Principal

Agora, vamos integrar o OneSignalEntry() no nosso layout principal. No exemplo abaixo, estamos usando o expo-router para a navegação e o ThemeProvider para alternar entre temas claro e escuro.

import FontAwesome from '@expo/vector-icons/FontAwesome';
import { DarkTheme, DefaultTheme, ThemeProvider } from '@react-navigation/native';
import { useFonts } from 'expo-font';
import { SplashScreen, Stack } from 'expo-router';
import { useEffect } from 'react';
import { useColorScheme } from 'react-native';
import { OneSignalEntry } from '../Utils/OneSignal';

export const unstable_settings = {
  initialRouteName: '(tabs)',
};

SplashScreen.preventAutoHideAsync();

export default function RootLayout() {
  const [loaded, error] = useFonts({
    SpaceMono: require('../assets/fonts/SpaceMono-Regular.ttf'),
    ...FontAwesome.font,
  });

  useEffect(() => {
    if (error) throw error;
  }, [error]);

  useEffect(() => {
    if (loaded) {
      SplashScreen.hideAsync();
    }
  }, [loaded]);

  if (!loaded) {
    return null;
  }

  return <RootLayoutNav />;
}

function RootLayoutNav() {
  const colorScheme = useColorScheme();

  // Inicializando o OneSignal
  OneSignalEntry();

  return (
    <ThemeProvider value={colorScheme === 'dark' ? DarkTheme : DefaultTheme}>
      <Stack>
        <Stack.Screen name="(tabs)" options={{ headerShown: false }} />
        <Stack.Screen name="modal" options={{ presentation: 'modal' }} />
      </Stack>
    </ThemeProvider>
  );
}

Testando a Notificação

No dashboard do OneSignal, crie uma nova notificação e selecione o seu dispositivo para envio.
Verifique se o seu aplicativo está recebendo as notificações conforme configurado.

Este artigo abrange os passos essenciais para integrar o OneSignal com um projeto Expo. Com essa configuração, você já consegue enviar e gerenciar notificações push para os usuários do seu app!

Solving Performance Issues with Redis and Bull

fael — Tue, 10 Sep 2024 01:00:36 +0000

Introduction

In a fintech environment, system performance is crucial to ensuring that financial transactions are quick and secure. The ability to process a large volume of simultaneous requests without compromising user experience or overloading infrastructure is one of the main challenges. To achieve this, tools like Redis and Bull have played a fundamental role in our fintech.

In this article, I will share how we used Redis and Bull to solve performance problems, improve transaction response times, and ensure that our financial system remains scalable and efficient. I will also include a practical guide on how to implement Redis and Bull in NestJS.

The Problem: Slowness and System Overload

With the growth of our user base and the increase in daily transactions, we began to notice a drop in system performance, especially during peak hours. Operations such as payment processing, report generation, and notifications were starting to slow down, and server overload was becoming a real threat.

Additionally, the need to process each transaction synchronously was beginning to create bottlenecks, increasing response times for end users. We needed a way to optimize the processing of these tasks to avoid service degradation.

Solution 1: Optimization with Redis

To enhance performance and reduce latency in read and write operations, we implemented Redis as a caching solution. Redis is an in-memory database that allows for extremely fast access and writes, making it ideal for storing temporary or frequently accessed data.

Using Redis in Our Infrastructure

Session and Authentication Cache: Instead of making constant database queries to check active sessions, we started storing authentication tokens in Redis. This significantly reduced latency in user authentications and transaction processing.
Temporary Transaction Cache: During payment processing, transaction data is temporarily stored in Redis before being written to the main database. This allowed us to process transactions much faster while the system handled critical operations asynchronously.
Reduction of Database Queries: We stored frequently accessed data in Redis, such as configuration information, payment states, and temporary logs. This reduced the load on the relational database and improved response times for end users.

Results

The implementation of Redis significantly reduced latency in several critical parts of our system, especially in operations that rely on quick and repeated queries. The improvement was noticeable on both the front-end, with faster response times, and the back-end, which handled the increased requests better.

Solution 2: Asynchronous Processing with Bull

Even with optimization through Redis, we found that some operations needed to be decoupled from the main flow, particularly tasks that required more processing time, such as transaction notifications, report generation, and integration with external systems.

This is where we implemented Bull, a queue management library based on Redis, which allowed us to process tasks asynchronously without blocking the main execution flow.

Using Bull for Queue Management

Asynchronous Transaction Processing: Instead of processing all transactions synchronously, we moved parts of the process to a task queue with Bull. This allowed our application to continue responding quickly to users while longer tasks were processed in the background.
Real-Time Notifications: One of the first applications of Bull was in the queue for sending notifications. Since sending notifications via email or push can be time-consuming and involves calls to external APIs, we moved this process to a queue, ensuring that users received their updates without impacting the overall platform performance.
Retry and Failure Management: Bull also allowed us to manage task failures efficiently. When a task failed, it was automatically reprocessed after a configured time, without the need for manual intervention, ensuring greater system resilience.

Results

By introducing Bull, we were able to distribute the workload more efficiently and avoid blocking the main application flow. This resulted in a significant improvement in response times, even during peak usage times. Furthermore, we were able to scale more predictably, as tasks were processed according to the system's capacity.

Practical Implementation: Integrating Redis and Bull in NestJS

Below, I present a step-by-step guide on how to integrate Redis and Bull into a NestJS application, based on the lessons learned from our practical experience.

1. Installing Dependencies

First, install the Bull and Redis packages in your NestJS project:

npm install @nestjs/bull bull redis
npm install @types/redis --save-dev

2. Configuring the Bull Module

Create a module to configure Bull with Redis. In queue.module.ts, register Bull:

import { BullModule } from '@nestjs/bull';
import { Module } from '@nestjs/common';
import { QueueProcessor } from './queue.processor';
import { QueueService } from './queue.service';

@Module({
  imports: [
    BullModule.forRoot({
      redis: {
        host: 'localhost',
        port: 6379,
      },
    }),
    BullModule.registerQueue({
      name: 'email', // Name of the queue
    }),
  ],
  providers: [QueueProcessor, QueueService],
  exports: [QueueService],
})
export class QueueModule {}

3. Creating the Queue Processor

Create queue.processor.ts to process tasks in the queue:

import { Processor, Process } from '@nestjs/bull';
import { Job } from 'bull';

@Processor('email') // Name of the queue we will process
export class QueueProcessor {
  @Process() // Here we handle the processing of each job
  async handleEmailJob(job: Job) {
    console.log(`Processing job #${job.id} with data:`, job.data);

    // Simulate sending email
    const { to, subject, text } = job.data;
    await this.sendEmail(to, subject, text);

    console.log('Email sent successfully');
  }

  private async sendEmail(to: string, subject: string, text: string) {
    // Simulate sending email (place your logic here)
    return new Promise((resolve) => {
      setTimeout(() => {
        console.log(`Email sent to: ${to}, with subject: ${subject}`);
        resolve(true);
      }, 3000);
    });
  }
}

4. Service for Adding Tasks to the Queue

Create a service to add new tasks to the queue in queue.service.ts:

import { Injectable } from '@nestjs/common';
import { InjectQueue } from '@nestjs/bull';
import { Queue } from 'bull';

@Injectable()
export class QueueService {
  constructor(@InjectQueue('email') private emailQueue: Queue) {}

  async addEmailJob(to: string, subject: string, text: string) {
    await this.emailQueue.add({
      to,
      subject,
      text,
    });
  }
}

5. Using the Service in the Controller

Create a controller to expose this functionality. In email.controller.ts:

import { Controller, Post, Body } from '@nestjs/common';
import { QueueService } from './queue.service';

@Controller('email')
export class EmailController {
  constructor(private readonly queueService: QueueService) {}

  @Post('send')
  async sendEmail(
    @Body('to') to: string,
    @Body('subject') subject: string,
    @Body('text') text: string,
  ) {
    await this.queueService.addEmailJob(to, subject, text);
    return { message: 'Email added to the queue!' };
  }
}

Testing the Implementation

Start Redis Locally: Ensure that Redis is running locally. You can use Docker to easily start Redis:

   docker run -p 6379:6379 redis

Run the Application: With Redis running, execute the NestJS application with the command:

   npm run start:dev

Send a Request: Now you can test the API using a tool like Postman or cURL, sending a POST request to http://localhost:3000/email/send with the following body:

   {
     "to": "user@example.com",
     "subject": "Email Test",
     "text": "This is a test email."
   }

If everything is configured correctly, you will see console logs showing that the job was added to the queue and that the processor handled it.

General Benefits of the Implementation

This is a practical example of how to integrate Redis and Bull in NestJS to manage asynchronous tasks effectively. We use Redis as a foundation for Bull, which is responsible for efficiently managing task queues.

Conclusion

In this example, we demonstrated how to integrate Redis and Bull into a NestJS project to create a robust queue system where lengthy tasks are processed asynchronously. This approach is ideal for systems that need to manage large volumes of transactions or other operations requiring high performance and resilience.

Resolvendo Problemas de Performance com Redis e Bull

fael — Tue, 10 Sep 2024 00:58:52 +0000

Em um ambiente de fintech, a performance do sistema é crucial para garantir que transações financeiras sejam rápidas e seguras. A capacidade de processar um grande volume de requisições simultaneamente, sem prejudicar a experiência do usuário ou sobrecarregar a infraestrutura, é um dos principais desafios. Para alcançar isso, ferramentas como Redis e Bull têm desempenhado um papel fundamental na nossa fintech.

Neste artigo, vou compartilhar como usamos Redis e Bull para resolver problemas de performance, melhorar o tempo de resposta das transações e garantir que nosso sistema financeiro continue escalável e eficiente. Também incluirei um guia prático sobre como implementar Redis e Bull no NestJS.

O Problema: Lentidão e Sobrecarga do Sistema

Com o crescimento da nossa base de usuários e o aumento no número de transações diárias, começamos a perceber uma queda na performance do sistema, especialmente durante os horários de pico. Operações como processamento de pagamentos, geração de relatórios e notificações estavam começando a ficar mais lentas, e a sobrecarga nos servidores estava se tornando uma ameaça real.

Além disso, a necessidade de processar cada transação de forma síncrona estava começando a causar gargalos, aumentando o tempo de resposta para o usuário final. Precisávamos de uma maneira de otimizar o processamento dessas tarefas para evitar a degradação do serviço.

Solução 1: Otimização com Redis

Para melhorar o desempenho e diminuir a latência nas operações de leitura e gravação, implementamos Redis como solução de cache. Redis é um banco de dados em memória que permite acessos e gravações extremamente rápidos, ideal para armazenar dados temporários ou frequentemente acessados.

Uso de Redis na Nossa Infraestrutura

Cache de Sessão e Autenticação: Em vez de fazer consultas constantes ao banco de dados para verificar sessões ativas, passamos a armazenar tokens de autenticação no Redis. Isso reduziu significativamente a latência nas autenticações de usuários e no processamento de transações.
Cache de Transações Temporárias: Durante o processamento de pagamentos, os dados da transação são armazenados temporariamente no Redis antes de serem gravados no banco de dados principal. Isso nos permitiu processar as transações de forma muito mais rápida, enquanto o sistema lida com operações críticas de forma assíncrona.
Redução de Consultas ao Banco de Dados: Armazenamos dados frequentemente acessados no Redis, como informações de configuração, estados de pagamentos e logs temporários. Isso reduziu a carga no banco de dados relacional e melhorou o tempo de resposta para os usuários finais.

Resultados

A implementação de Redis reduziu significativamente a latência em várias partes críticas do nosso sistema, especialmente nas operações que dependem de consultas rápidas e repetidas. A melhora foi perceptível tanto no front-end, com tempos de resposta mais rápidos, quanto no back-end, que suportava melhor o aumento de requisições.

Solução 2: Processamento Assíncrono com Bull

Mesmo com a otimização via Redis, percebemos que algumas operações precisavam ser desacopladas do fluxo principal, especialmente tarefas que demandavam mais tempo de processamento, como notificações de transações, geração de relatórios e integração com sistemas externos.

Foi aí que implementamos Bull, uma biblioteca de gerenciamento de filas baseada em Redis, que nos permitiu processar tarefas de maneira assíncrona, sem bloquear o fluxo principal de execução.

Uso de Bull para Gerenciamento de Filas

Processamento de Transações Assíncronas: Em vez de processar todas as transações de forma síncrona, movemos partes do processo para uma fila de tarefas com Bull. Isso permitiu que nossa aplicação continuasse respondendo rapidamente aos usuários, enquanto tarefas mais demoradas eram processadas em segundo plano.
Notificações em Tempo Real: Uma das primeiras aplicações de Bull foi na fila de envio de notificações. Como o envio de notificações por e-mail ou push pode ser demorado e envolvem chamadas a APIs externas, movemos esse processo para uma fila, garantindo que os usuários recebessem suas atualizações sem impactar o desempenho geral da plataforma.
Gerenciamento de Retries e Falhas: Bull também nos permitiu gerenciar falhas em tarefas de forma eficiente. Quando uma tarefa falhava, era reprocessada automaticamente após um tempo configurado, sem necessidade de intervenção manual, garantindo maior resiliência do sistema.

Resultados

Ao introduzir Bull, conseguimos distribuir a carga de trabalho de maneira mais eficiente e evitar o bloqueio do fluxo principal da aplicação. Isso resultou em uma melhoria significativa no tempo de resposta, mesmo em momentos de pico de uso. Além disso, conseguimos escalar de forma mais previsível, já que as tarefas eram processadas conforme a capacidade do sistema.

Implementação Prática: Integrando Redis e Bull no NestJS

Abaixo, apresento um guia passo a passo sobre como integrar Redis e Bull em uma aplicação NestJS, a partir das lições aprendidas na nossa experiência prática.

1. Instalação das Dependências

Primeiro, instale os pacotes do Bull e Redis no seu projeto NestJS:

npm install @nestjs/bull bull redis
npm install @types/redis --save-dev

2. Configuração do Módulo Bull

Crie um módulo para configurar Bull com Redis. No queue.module.ts, registre o Bull:

import { BullModule } from '@nestjs/bull';
import { Module } from '@nestjs/common';
import { QueueProcessor } from './queue.processor';
import { QueueService } from './queue.service';

@Module({
  imports: [
    BullModule.forRoot({
      redis: {
        host: 'localhost',
        port: 6379,
      },
    }),
    BullModule.registerQueue({
      name: 'email', // Nome da fila
    }),
  ],
  providers: [QueueProcessor, QueueService],
  exports: [QueueService],
})
export class QueueModule {}

3. Criar o Processador de Filas

Crie o queue.processor.ts para processar as tarefas na fila:

import { Processor, Process } from '@nestjs/bull';
import { Job } from 'bull';

@Processor('email') // Nome da fila que vamos processar
export class QueueProcessor {
  @Process() // Aqui lidamos com o processamento de cada job
  async handleEmailJob(job: Job) {
    console.log(`Processando job #${job.id} com os dados:`, job.data);

    // Simular envio de e-mail
    const { to, subject, text } = job.data;
    await this.sendEmail(to, subject, text);

    console.log('Email enviado com sucesso');
  }

  private async sendEmail(to: string, subject: string, text: string) {
    // Simulação de envio de e-mail (coloque sua lógica aqui)
    return new Promise((resolve) => {
      setTimeout(() => {
        console.log(`Email enviado para: ${to}, com assunto: ${subject}`);
        resolve(true);
      }, 3000);
    });
  }
}

4. Serviço para Adicionar Tarefas à Fila

Crie um serviço para adicionar novas tarefas na fila em queue.service.ts:

import { Injectable } from '@nestjs/common';
import { InjectQueue } from '@nestjs/bull';
import { Queue } from 'bull';

@Injectable()
export class QueueService {
  constructor(@InjectQueue('email') private emailQueue: Queue) {}

  async addEmailJob(to: string, subject: string, text: string) {
    await this.emailQueue.add({
      to,
      subject,
      text,
    });
  }
}

5. Usando o Serviço no Controller

Crie um controlador para expor essa funcionalidade. No email.controller.ts:

import { Controller, Post, Body } from '@nestjs/common';
import { QueueService } from './queue.service';

@Controller('email')
export class EmailController {
  constructor(private readonly queueService: QueueService) {}

  @Post('send')
  async sendEmail(
    @Body('to') to: string,
    @Body('subject') subject: string,
    @Body('text') text: string,
  ) {
    await this.queueService.addEmailJob(to, subject, text);
    return { message: 'Email adicionado à fila!' };
  }
}

Testando a Implementação

Suba o Redis localmente:

Para testar, certifique-se de que o Redis esteja rodando localmente. Você pode usar o Docker para iniciar o Redis facilmente:

   docker run -p 6379:6379 redis

Execute o aplicativo:

Com o Redis rodando, execute o NestJS com o comando:

   npm run start:dev

Envie uma requisição:

Agora, você pode testar a API com uma ferramenta como o Postman ou cURL, enviando uma requisição POST para http://localhost:3000/email/send com o seguinte body:

   {
     "to": "usuario@example.com",
     "subject": "Teste de Email",
     "text": "Esse é um email de teste."
   }

Se tudo estiver configurado corretamente, você verá no console logs mostrando que o job foi adicionado à fila e que o processador lidou com ele.

Benefícios Gerais das Implementação

Aqui está um exemplo prático de como integrar Redis e Bull no NestJS para gerenciar tarefas assíncronas. Vamos usar o Redis como uma base para o Bull, que será responsável por gerenciar filas de tarefas de forma eficiente.

Conclusão

Neste exemplo, mostramos como integrar Redis e Bull em um projeto NestJS para criar um sistema de filas robusto, onde tarefas demoradas são processadas de forma assíncrona. Essa abordagem é ideal para sistemas que precisam gerenciar grandes volumes de transações ou outras operações que exigem alta performance e resiliência.

The Challenges of Managing a Successful Fintech: Revenue of R$9,643,141.49 in 30 Days

fael — Mon, 09 Sep 2024 22:53:30 +0000

Running a fintech that generated over R$9.6 million in just 30 days comes with a range of complex challenges. From the perspective of a senior developer, each day is marked by decisions that can profoundly impact the business. When working with a tech stack comprised of NestJS, Redis, PostgreSQL, and NextJS, the focus is on ensuring that the system is scalable, performant, and secure. However, the reality extends far beyond simply choosing the right tools.

1. Constant Pressure: No Room for Error

In an environment where millions of reais are at stake, the margin for error is virtually nonexistent. Every technical decision, whether in the architecture or in implementing a new feature, can directly affect the business and its customers. The pressure to ensure that every transaction is processed flawlessly is constant. A simple mistake, such as an inefficient query or a misconfigured cache, can result in significant financial loss.

NestJS, being modular and efficient, helps in organizing the code, but the pressure to maintain everything running smoothly forces an extremely careful approach to each new deployment. Every line of code undergoes thorough reviews and automated testing before being applied, ensuring that there is no impact on transactions.

2. Continuous Monitoring and Maintenance

Real-time monitoring is essential for ensuring that the fintech operates efficiently. Tools like Sentry for error tracking and Grafana for performance metrics are critical in daily operations. They provide a detailed view of how the system is behaving and help detect potential failures before they escalate into larger problems.

Redis plays a vital role in handling high transaction volumes by offloading some of the processing through queues and caching. However, the technical team must always be vigilant to ensure that no transaction queue gets stuck, as this could directly affect the user experience and lead to significant delays.

3. Scalability and Data Consistency

Maintaining scalability in a system processing millions of reais requires a well-thought-out architecture. PostgreSQL, our database, needs continuous optimization, including table partitioning and well-defined indexes to handle the growing data volume without compromising performance. Every query must be optimized, and backup routines are constant to prevent data loss.

The combination of NestJS and PostgreSQL allows for a scalable backend structure, but ensuring data consistency in complex financial transactions is an ongoing challenge. We need to handle concurrency and distributed transactions, which adds a layer of complexity to the development process.

4. Frontend Development with NextJS

The frontend, built with NextJS, must be fast and intuitive, providing real-time dashboards that display critical financial data to clients. User experience is paramount, and leveraging server-side rendering (SSR) with NextJS ensures a fast interface, even when dealing with a high volume of data exchanged between frontend and backend.

5. Decision-Making Under Pressure

In a fintech environment, quick decision-making is part of the daily routine. When an issue is detected, there is little time for deliberation. Immediate action is required to mitigate any damage. A simple few-minute downtime can have a direct financial impact on clients and damage the platform's reputation. This is why we have strict protocols in place to handle failures, including deploy rollbacks and immediate recovery procedures.

Setting up alerts to monitor API performance and potential bottlenecks is critical. If an endpoint starts to show issues, we receive instant notifications and often have to resolve the problem in a matter of minutes—or even seconds.

6. Balancing Productivity and Quality of Life

Handling large financial volumes and the constant pressure to keep the platform running smoothly can be exhausting. However, it's essential to maintain a balance between productivity and quality of life to avoid burnout. Collaboration between teams is key, and we strive to foster a culture of mutual support, where challenges are shared and solved together.

Conclusion

Managing a fintech with such significant revenue requires not only advanced technical skills but also the ability to handle pressure and make swift decisions. The stack of NestJS, Redis, PostgreSQL, and NextJS allows us to build a solid and scalable architecture, but the responsibility of keeping everything running without failure is a continuous challenge. In the end, the reward lies in knowing we are building a reliable platform that simplifies financial life for thousands of users, all while continuing to grow and innovate.

Os Desafios de Gerenciar uma Fintech de Sucesso: Faturamento de R$9.643.141,49 em 30 Dias

fael — Mon, 09 Sep 2024 22:49:58 +0000

Gerenciar uma fintech que faturou mais de R$9,6 milhões em apenas 30 dias traz uma série de desafios complexos. Para quem está do lado técnico, especialmente como desenvolvedor sênior, cada dia é marcado por decisões que podem impactar profundamente a empresa. Quando estamos trabalhando com uma stack composta por NestJS, Redis, PostgreSQL e NextJS, o foco está sempre em garantir que o sistema seja escalável, performático e seguro, mas a realidade vai muito além da escolha de boas ferramentas.

1. A Pressão Constante de Não Poder Errar

Em um ambiente onde se movimentam milhões de reais, a margem para erro é praticamente inexistente. Cada pequena decisão técnica, seja na arquitetura ou na implementação de uma nova funcionalidade, pode afetar diretamente o negócio e, por consequência, os clientes e parceiros. A pressão de garantir que todas as transações sejam processadas corretamente, sem falhas, é constante. Um erro simples, como uma consulta mal otimizada ou uma configuração errada de cache, pode significar prejuízos consideráveis.

O NestJS, sendo modular e eficiente, ajuda na organização de código, mas a pressão de manter tudo funcionando sem falhas leva a uma abordagem extremamente cuidadosa para cada novo deploy. Cada linha de código passa por revisões rigorosas e testes automatizados antes de ser aplicada, garantindo que não haja impacto nas transações.

2. Monitoramento e Manutenção Contínuos

O monitoramento em tempo real é outro fator crucial para garantir que a fintech funcione de maneira eficiente. Ferramentas como Sentry para captura de erros e Grafana para métricas de performance são essenciais no dia a dia. Elas nos permitem ter uma visão detalhada de como o sistema está se comportando e detectar potenciais falhas antes que causem um problema maior.

O uso de Redis para filas de processamento e cache é estratégico para lidar com o alto volume de transações. Ele ajuda a aliviar a carga no banco de dados e distribui o processamento de eventos de maneira eficiente, mas a equipe técnica precisa estar sempre atenta para garantir que nenhuma fila de transação trave, pois isso pode afetar diretamente a experiência dos usuários e causar grandes atrasos.

3. Escalabilidade e Consistência de Dados

Manter a escalabilidade de um sistema que processa milhões de reais exige uma arquitetura bem planejada. PostgreSQL, o banco de dados que usamos, requer otimizações contínuas, como particionamento de tabelas e índices bem definidos, para lidar com o crescente volume de dados sem comprometer a performance. Cada consulta precisa ser otimizada, e as rotinas de backup são constantes para evitar qualquer perda de dados.

A combinação de NestJS e PostgreSQL permite que a estrutura do backend seja escalável, mas garantir a consistência dos dados em transações financeiras complexas é um desafio constante. Precisamos lidar com cenários de concorrência e transações distribuídas, o que torna o desenvolvimento ainda mais desafiador.

4. Desenvolvimento de Frontend com NextJS

O frontend, desenvolvido com NextJS, precisa ser rápido e intuitivo, fornecendo dashboards em tempo real que mostram dados financeiros críticos para os clientes. A experiência do usuário é fundamental, e o uso de SSR (server-side rendering) no NextJS ajuda a garantir uma interface rápida, mesmo com um volume elevado de dados sendo trocado entre o frontend e o backend.

5. Tomada de Decisões Sob Pressão

No ambiente de uma fintech, a tomada de decisões rápidas é parte do dia a dia. Quando um problema é detectado, não há tempo para muita deliberação. É preciso agir imediatamente para mitigar os danos. Um simples downtime de minutos pode ter um impacto direto nas finanças dos clientes e prejudicar a confiança na plataforma. Por isso, temos protocolos rígidos para lidar com falhas, incluindo rollback de deploys e procedimentos de recuperação imediata.

Ter alertas configurados para monitorar a performance das APIs e possíveis gargalos é fundamental. Se um endpoint começa a apresentar problemas, recebemos notificações instantâneas e, muitas vezes, temos que resolver o problema em questão de minutos, ou até segundos.

6. Manter o Equilíbrio: Produtividade e Qualidade de Vida

Lidar com grandes volumes financeiros e a constante pressão para manter a plataforma operando com eficiência pode ser exaustivo. No entanto, é essencial manter um equilíbrio entre produtividade e qualidade de vida para evitar o desgaste excessivo da equipe. A colaboração entre os times é fundamental, e buscamos ter uma cultura de suporte mútuo, onde as dificuldades são compartilhadas e resolvidas em conjunto.

Conclusão

Gerenciar uma fintech com um faturamento expressivo como o nosso exige não apenas habilidades técnicas avançadas, mas também uma forte capacidade de lidar com pressão e tomar decisões rapidamente. A stack composta por NestJS, Redis, PostgreSQL e NextJS nos permite criar uma arquitetura sólida e escalável, mas a responsabilidade de manter tudo funcionando sem falhas é um desafio constante. No final, a recompensa é saber que estamos construindo uma plataforma confiável, que facilita a vida financeira de milhares de usuários, ao mesmo tempo em que continuamos crescendo e inovando.

DEV Community: fael

Migrando do RDS PostgreSQL para Aurora Serverless

O Problema: Escalabilidade e Custos em um Ambiente Imprevisível

A Solução: Aurora Serverless

O Processo de Migração

Os Resultados

Conclusão

Pix

Testes de Carga com K6

Introdução

Por Que Realizar Testes de Carga?

Conclusão

ACID Transactions em uma Aplicação Fintech:

Introdução

Entendendo as Propriedades ACID

1. Atomicidade (Atomicity)

2. Consistência (Consistency)

3. Isolamento (Isolation)

4. Durabilidade (Durability)

Conclusão

Ensuring Data Integrity in Financial Transactions: The PostgreSQL Transaction Solution

What Are Banking Transactions?

The Solution: Transactions in PostgreSQL

How Does a Transaction Work in PostgreSQL?

Practical Example Using NestJS and Prisma

Configuring Prisma with PostgreSQL

Implementing Transactions in NestJS with Prisma

Service Code

Code Explanation:

Benefits of Transactions for Banking Systems

Final Considerations

Garantindo a Integridade de Dados em Transações Financeiras: A Solução com Transações no PostgreSQL

O Que São Transações Bancárias?

A Solução: Transações no PostgreSQL

Como Funciona uma Transação no PostgreSQL?

Exemplo Prático Usando NestJS e Prisma

Configuração do Prisma com PostgreSQL

Implementando Transações no NestJS com Prisma

Código do Serviço

Explicação do Código:

Benefícios das Transações para Sistemas Bancários

Considerações Finais

Aplicando SOLID no NestJS

Introdução

Princípio da Responsabilidade Única (SRP)

Exemplo de Aplicação SRP no NestJS

Princípio Aberto/Fechado (OCP)

Exemplo de Aplicação OCP no NestJS

Princípio da Substituição de Liskov (LSP)

Exemplo de Aplicação LSP no NestJS

Princípio da Segregação de Interface (ISP)

Exemplo de Aplicação ISP no NestJS

Princípio da Inversão de Dependência (DIP)

Exemplo de Aplicação DIP no NestJS

Conclusão

Explorando Notificações Push no React Native com Expo e OneSignal!

Configurando Notificações Push no Expo com OneSignal

Pré-requisitos

Passo 1: Configurando o app.json com o OneSignal

Passo 2: Inicializando o OneSignal no Projeto

Passo 3: Integração no Componente Principal

Testando a Notificação

Solving Performance Issues with Redis and Bull

Introduction

The Problem: Slowness and System Overload

Solution 1: Optimization with Redis

Using Redis in Our Infrastructure

Results

Solution 2: Asynchronous Processing with Bull

Using Bull for Queue Management

Results

Practical Implementation: Integrating Redis and Bull in NestJS

1. Installing Dependencies

2. Configuring the Bull Module

3. Creating the Queue Processor

4. Service for Adding Tasks to the Queue

5. Using the Service in the Controller

Testing the Implementation

General Benefits of the Implementation

Conclusion

Passo 1: Configurando o `app.json` com o OneSignal