DEV Community: 3X Pay

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.

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.

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.

Certificados RSA e a Segurança na 3XPay

fael — Thu, 05 Sep 2024 12:52:14 +0000

Certificados RSA e a Segurança na 3XPay

Introdução

Em um mundo digital onde as transações financeiras estão cada vez mais vulneráveis a ataques cibernéticos, garantir a segurança dos dados é essencial, especialmente para fintechs. Na 3XPay, a segurança sempre foi uma prioridade, e para proteger as comunicações entre os usuários e nossa API, adotamos o RSA como parte fundamental da nossa estratégia de criptografia. Neste artigo, vamos explorar o que são certificados RSA, como funcionam e como foram implementados na 3XPay para garantir a proteção dos nossos usuários.

O Que é o RSA?

O RSA (Rivest-Shamir-Adleman) é um dos algoritmos de criptografia mais utilizados para proteger comunicações na web. Ele é um método de criptografia de chave pública, o que significa que utiliza duas chaves distintas:

Chave pública: usada para criptografar os dados.
Chave privada: usada para descriptografar os dados.

O grande benefício do RSA é que, mesmo que a chave pública seja compartilhada com qualquer pessoa, apenas a chave privada correspondente pode descriptografar os dados, garantindo que a informação permaneça segura durante a transmissão.

Como o RSA Funciona?

A segurança do RSA baseia-se em conceitos de teoria dos números, especificamente na dificuldade de fatorar grandes números primos. O processo pode ser resumido em três etapas principais:

Geração de Chaves: Dois números primos grandes são selecionados e multiplicados para criar uma chave pública e uma chave privada.
Criptografia: Os dados são criptografados com a chave pública, tornando-os ilegíveis para qualquer pessoa que não tenha a chave privada.
Descriptografia: Somente o proprietário da chave privada pode descriptografar e acessar os dados originais.

A Importância do RSA na 3XPay

A 3XPaylida diariamente com um grande volume de transações financeiras entre nossos usuários e a API. Garantir que essas transações sejam seguras é essencial, pois qualquer vazamento de dados pode comprometer informações sensíveis, como detalhes de cartões de crédito e dados pessoais dos clientes.

Ao implementar o RSA, conseguimos garantir que todas as comunicações entre os nossos usuários e a nossa API sejam criptografadas, protegendo os dados em trânsito contra ataques de man-in-the-middle (MitM) e interceptações maliciosas.

Como o RSA foi Aplicado

Na 3XPay, aplicamos a criptografia RSA em diversos pontos do nosso sistema para garantir a máxima segurança. Aqui estão algumas formas de como o RSA é utilizado:

Criptografia de Dados em Trânsito:
- Todas as requisições feitas pelos usuários para nossa API passam por um processo de criptografia. Usamos o SSL/TLS com certificados RSA para criptografar essas comunicações, garantindo que qualquer dado transmitido entre o cliente e os servidores da 3XPay permaneça seguro.
- Mesmo que alguém consiga interceptar os pacotes de dados, eles não serão capazes de descriptografá-los sem a chave privada.
Autenticação Segura:
- O RSA também é usado para autenticar a identidade dos nossos servidores e garantir que os usuários estão realmente se conectando à gente, e não a um site malicioso. Isso é feito por meio de certificados digitais emitidos por autoridades certificadoras (CAs) confiáveis, que garantem que o domínio e a chave pública pertencem realmente à nós.
Proteção de Dados Sensíveis:
- Dados altamente sensíveis, como informações financeiras e pessoais, são criptografados utilizando RSA antes de serem armazenados. Assim, mesmo em caso de uma violação de dados, as informações estariam protegidas.

Benefícios da Criptografia RSA na 3XPay

A implementação do RSA trouxe vários benefícios para a plataforma:

Segurança Aumentada: Com o uso de RSA, a comunicação entre usuários e a API é protegida contra interceptações. Mesmo que um atacante capture os dados, ele não conseguirá descriptografá-los sem a chave privada.
Confiança do Cliente: Ao garantir a segurança das transações, conquistamos a confiança dos nossos usuários, que podem realizar pagamentos sabendo que suas informações estão protegidas.
Compliance: A plataforma também cumpre regulamentações de segurança, como PCI-DSS, exigidas em transações financeiras. O uso de criptografia RSA faz parte das melhores práticas para proteção de dados financeiros.

Conclusão

O uso de RSA foi fundamental para garantir a segurança das transações na. A criptografia de ponta a ponta, somada à autenticação confiável, assegura que nossos usuários podem confiar na proteção de seus dados, desde o momento em que inserem suas informações até a confirmação da transação.

Ao investir em criptografia RSA e em certificados digitais, fortalecemos ainda mais como uma plataforma de pagamentos segura e confiável, pronta para atender às demandas crescentes do mercado de fintechs.

Próximos Passos

Na 3XPay, continuamos a evoluir nossas práticas de segurança, garantindo que nossos usuários tenham sempre o mais alto nível de proteção. Se você deseja saber mais sobre como implementamos criptografia RSA ou sobre outras medidas de segurança que adotamos, entre em contato conosco!

Por que escolhi AWS ECS para uma fintech e não o Serveless

fael — Thu, 05 Sep 2024 12:00:19 +0000

Fintechs operam em um ambiente altamente dinâmico e regulamentado, onde velocidade, segurança e escalabilidade são essenciais. A escolha da infraestrutura correta pode determinar o sucesso ou fracasso de uma aplicação financeira. Enquanto muitas startups optam por soluções serverless, como AWS Lambda, há situações onde o AWS ECS Fargate se destaca como uma escolha mais adequada. Neste artigo, destacamos por que uma fintech deveria optar pelo ECS Fargate em vez de uma arquitetura serverless, com base em minha experiência prática de enfrentamento de problemas como cold starts e limitações no tamanho do deploy.

Minha experiência com o serveless

Em um projeto recente de uma fintech, onde construí uma plataforma de pagamentos, inicialmente adotamos uma arquitetura serverless usando o AWS Lambda por sua promessa de escalabilidade automática e gerenciamento simplificado. A ideia de pagar apenas pelo tempo de execução era atraente, mas logo nos deparamos com desafios críticos que afetaram a performance e a experiência do usuário.

O Problema do Cold Start

Nosso sistema precisava processar transações em tempo real, respondendo a requisições de pagamento de forma imediata. No entanto, o cold start do serverless tornou-se um gargalo significativo. A cada vez que uma função Lambda era invocada pela primeira vez ou após um período de inatividade, o tempo de resposta da requisição aumentava drasticamente. Essa latência era inaceitável em uma fintech, onde cada segundo conta, especialmente em transações financeiras sensíveis.

Experiência: O cold start, particularmente durante picos de atividade, causava atrasos perceptíveis. Tínhamos que implementar soluções de aquecimento (warming) para manter as funções "quentes", mas isso aumentava a complexidade e não eliminava completamente o problema. Em um cenário onde a confiabilidade e velocidade são essenciais, o serverless falhou em oferecer a consistência de performance que precisávamos.

Limitações no Tamanho do Deploy

Outro problema surgiu com o crescimento da aplicação. Com a expansão da plataforma, as bibliotecas e dependências do sistema cresceram em complexidade, e as limitações de tamanho de deploy no Serverless Framework começaram a ser um obstáculo. Tínhamos que reestruturar pacotes e eliminar funcionalidades essenciais para caber no limite permitido.

Experiência: Essa limitação de tamanho obrigou nossa equipe a buscar soluções alternativas, como dividir funções ou reduzir o uso de bibliotecas pesadas, mas isso comprometia a agilidade no desenvolvimento. A fintech precisava de um sistema robusto que suportasse suas dependências sem restrições.

A Mudança para AWS ECS Fargate

Com os desafios de cold start e limitações de deploy no serverless, decidimos migrar nossa plataforma de pagamento para o AWS ECS Fargate. Essa mudança trouxe uma série de benefícios para a arquitetura da fintech.

1. Eliminação do Cold Start

No ECS Fargate, os containers podem ser mantidos em execução por longos períodos, eliminando a latência de inicialização que tanto afetava nossa plataforma no serverless. Isso trouxe uma melhoria imediata na performance, especialmente em transações de pagamento que exigiam respostas rápidas e consistentes.

Experiência: Após a migração para o Fargate, notamos uma drástica redução na latência das requisições. As transações passaram a ser processadas quase instantaneamente, e o problema de cold start desapareceu completamente. A consistência de resposta foi crucial para a confiança dos nossos usuários.

2. Escalabilidade Automática e Controle de Custos

Assim como o serverless, o ECS Fargate oferece escalabilidade automática, mas com o benefício adicional de maior controle sobre os recursos alocados (CPU e memória). Em uma fintech, onde o volume de transações pode variar ao longo do dia, a capacidade de ajustar a infraestrutura com precisão foi um ponto positivo.

Experiência: Com o Fargate, conseguimos escalar nossa aplicação de forma dinâmica, ajustando os containers com base na demanda. Além disso, a opção de usar Spot Instances no Fargate nos permitiu reduzir custos sem sacrificar o desempenho.

3. Flexibilidade no Tamanho do Deploy

A principal vantagem do ECS Fargate em relação ao serverless foi a liberdade em termos de deploy. Não havia mais as rígidas limitações de tamanho, permitindo que nossa aplicação mantivesse todas as suas dependências e bibliotecas intactas, sem a necessidade de comprometer funcionalidades.

Experiência: A migração para containers eliminou a frustração de lidar com limites de tamanho de pacote. Agora, podíamos fazer deploy de atualizações complexas sem nos preocupar com restrições, acelerando o ciclo de desenvolvimento e entregando novas funcionalidades mais rapidamente.

4. Ambiente Controlado e Seguro

Com o ECS Fargate, também ganhamos controle granular sobre o ambiente de execução, algo crítico para garantir conformidade com normas regulatórias, como PCI DSS. A capacidade de configurar redes privadas, grupos de segurança e políticas de acesso específicas nos deu maior controle sobre a segurança da plataforma.

Experiência: Para uma fintech, a segurança é primordial. O controle oferecido pelo Fargate nos permitiu isolar partes críticas da aplicação e garantir que todos os dados fossem processados em um ambiente seguro e conforme as exigências regulatórias.

Conclusão

Para fintechs, a escolha entre Serverless e ECS Fargate depende das necessidades específicas do projeto. Enquanto o serverless pode ser adequado para cargas de trabalho simples e intermitentes, enfrentamos desafios com cold starts e limitações de deploy que prejudicaram a performance e a escalabilidade da nossa plataforma de pagamentos.

O AWS ECS Fargate emergiu como a solução ideal, oferecendo maior controle, escalabilidade sem comprometimentos e eliminação dos problemas de latência. Para fintechs que lidam com operações financeiras críticas, a consistência e a flexibilidade do Fargate fazem dele a escolha superior.