Perguntas e Dúvidas Frequentes

O PulseSocketDB é uma engine de banco de dados em tempo real (BaaS) de código aberto e auto-hospedada, criada como uma alternativa leve ao Firebase. Ele permite que você gerencie regras de segurança e autenticação através de um Control Plane enquanto mantém 100% dos seus dados armazenados de forma soberana na sua própria VPS ou infraestrutura Redis.

Não. O PulseSocketDB foi desenvolvido com isolamento completo: • Porta Isolada: A API roda na porta 3001 por padrão, totalmente independente de outras aplicações (como portas 3000, 8080, etc). • Roteamento Nginx: O Nginx gerencia subdomínios (ex: api.pulsesocketdb.com) apontando internamente para a porta do PulseSocketDB. • Processos Isolados: Cada serviço roda em um processo PM2/Docker próprio. Se uma aplicação reiniciar, as outras continuam rodando sem interrupções.

• Mínimo (Testes / Ambientes Pequenos): 1 vCPU, 1 GB RAM, 10 GB SSD. Suficiente para dezenas de milhares de requisições dividindo o servidor com outro app leve. • Recomendado (Produção em Escala): 2 vCPUs, 4 GB RAM, 40 GB NVMe SSD. Garante desempenho ultra-rápido para Redis em RAM e suporte a milhares de conexões WebSocket simultâneas.

O PulseSocketDB garante zero colisões através de dois mecanismos principais: 1. Namespaces Prefixados: Todas as chaves utilizam identificadores únicos (ex: project_meta:*, user_redis_config:*, quota:*). 2. Bancos Lógicos (Redis DB Index): Você pode configurar a URL para usar um banco específico (ex: redis://127.0.0.1:6379/1), separando totalmente os dados do banco 0 padrão.

Sim! O PulseSocketDB conta com um gerenciador dinâmico de conexões (TenantConnectionManager). Usuários dos planos Pro e Enterprise podem conectar seus próprios clusters Redis (AWS ElastiCache, Upstash, Redis Enterprise), garantindo que 100% dos dados residam na própria infraestrutura do cliente.

No arquivo /etc/redis/redis.conf, ajuste os parâmetros maxmemory e maxmemory-policy: maxmemory 512mb maxmemory-policy noeviction Isso estabelece um teto rígido de memória, garantindo que o Redis nunca comprometa o sistema operacional ou outras aplicações rodando no servidor.

A Core API construída com Fastify é ultra-eficiente: • Consumo de RAM: ~100MB a 150MB em repouso. • Latência: < 5ms por requisição em memória RAM. • Proteção PM2: É recomendado rodar com --max-memory-restart 500M para reinício automático preventivo.

O PulseSocketDB fornece relatórios visuais em tempo real no Dashboard: • Total de Operações: Contagem precisa de Leituras (Reads) e Escritas (Writes). • Volume de Dados: Tamanho ocupado em MB/KB no Redis. • Conexões Simultâneas: Número de clientes conectados via WebSockets. • Status de Cotas: Alertas prévios ao se aproximar dos limites do plano assinado.

Ao atingir o limite do plano, o sistema responde com erro 429 Too Many Requests para novas requisições excedentes. Os dados salvos permanecem inteiramente seguros, e o cliente pode realizar o upgrade instantâneo de plano no Dashboard para restaurar os limites imediatamente.

O PulseSocketDB oferece o melhor dos dois mundos (Zero Lock-In): 1. SDK Oficial npm (pulsesocketdb): Para aplicações JavaScript/TypeScript (React, Vue, Node.js, Next.js, Nuxt), fornecemos a biblioteca oficial client-side com API encadeada inspirada no Firebase (ex: db.collection("pedidos").onSnapshot(...) e db.collection("pedidos").add(...)). 2. Protocolos Padrão (Sem SDK): Qualquer aplicação ou linguagem (PHP, Python, Go, C#, Flutter, cURL) pode se comunicar diretamente usando HTTP REST padrão (GET/POST/PUT/DELETE em /api/db/:colecao) para operações CRUD e WebSockets (Socket.io Client) para sincronização em tempo real.

Não! O pacote npm (pulsesocketdb) contém unicamente os arquivos compilados da pasta dist/ (configurado via o campo "files": ["dist"] no package.json). O repositório GitHub e todo o código do monorepo continuam 100% privados.

O SDK conta com reconexão automática e algoritmo de Exponential Backoff. Se a conexão WebSocket for perdida por oscilação de rede, o cliente tenta restabelecer o link automaticamente sem congelar a aplicação do usuário final.

Não, e esta é uma das diferenças arquiteturais mais importantes do PulseSocketDB. O sistema utiliza um modelo de multiplexação: independente de quantos clientes (100, 1.000 ou 10.000) estejam conectados simultaneamente, o Redis sempre recebe apenas 2 conexões fixas da Core API: • 1 conexão de comando (leituras e escritas) • 1 conexão de Pub/Sub (distribuição de eventos em tempo real) Os clientes conectam ao Node.js via WebSocket, e o Node.js serve como intermediário eficiente. O Redis jamais é exposto diretamente ao número de usuários do sistema. Essa arquitetura é a mesma utilizada pelo Firebase Realtime Database e pelo Supabase Realtime — produtos que atendem milhões de usuários com Redis.

Redis e bancos SQL têm modelos fundamentalmente diferentes: • PostgreSQL / MySQL: Cada cliente abre 1 conexão dedicada ao banco. Com 500 usuários simultâneos, são 500 conexões — um gargalo real que exige connection pools e replica sets. • Redis: É single-threaded com event loop. Processa 100.000+ operações por segundo em memória RAM numa única instância, sem travamentos. A escrita de um documento é uma operação HSET atômica de menos de 1 milissegundo. Portanto, a preocupação com "banco não suportar escritas simultâneas" é válida para sistemas SQL, mas não se aplica ao Redis, que foi projetado exatamente para este cenário de alto throughput com escritas frequentes.

O PulseSocketDB foi construído para um caso de uso específico: dados em tempo real com baixíssima latência. Redis é a escolha ideal porque: • Velocidade: Operações em memória com latência abaixo de 1ms (vs. dezenas de ms em disco com SQL). • Pub/Sub Nativo: Redis possui sistema de publicação/assinatura embutido, base do nosso sistema de sincronização em tempo real — sem polling ou triggers externos. • Estruturas de Dados Ricas: Hashes, Sets e Sorted Sets nativos facilitam operações que exigiriam queries complexas em SQL. • Sem Schema: Perfeito para dados dinâmicos que variam por projeto e cliente. Para dados que exigem SQL (relatórios complexos, joins, transações ACID multi-tabela), o PulseSocketDB não é a ferramenta correta — e somos honestos sobre isso. Nosso foco é sincronização de estado em tempo real, não substituição de bancos transacionais.