Pular para o conteúdo
thiagoetipadrões

Contatos

apps/patterns/singleton-pattern

029 · Padrões Fundamentais · ≈ 6 min de estudo

Singleton Pattern

Garante uma única instância de um recurso caro por processo, com um ponto de acesso global. Todo módulo que pede o pool de conexões ou o cliente de cache recebe o mesmo objeto, em vez de abrir conexões próprias. Use só para infraestrutura (pool, cache, config, cliente externo), nunca para entidade de domínio.

passos
6
arquivos
7
teste
1
tecnologias
6
Infraestrutura realTypeScriptBunElysiaPostgreSQLRedisDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Um banco digital lê saldos de vários módulos do mesmo processo. Vinte consultas simultâneas pelo pool singleton usam no máximo 5 conexões do PostgreSQL. O contraexemplo cria um pg.Pool por chamador e as mesmas vinte consultas abrem vinte conexões. No cache, o saldo que o módulo de extrato buscou no banco sai do Redis para o módulo de transferência.

Planta

Fluxo
6/6
Módulo de extratoPoolAccount (5 conexões)Módulo de transferênciaCacheBalance (1 cliente)PostgreSQLRedisgetInstance()getInstance()getInstance()getInstance()SQLGET/SET
6

6 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Uma única instância compartilhada.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

null+1
  1. 01

    Construtor privadonew PoolAccount() fora da classe não compila; o único acesso é getInstance()

  2. 02

    Criação preguiçosaA instância nasce na primeira chamada; o runtime é single-threaded, então a checagem de null dispensa lock

  3. 03

    Singleton assíncronoCacheBalance guarda a promessa da conexão, e dois chamadores que disputam o primeiro uso recebem o mesmo cliente

  4. 04

    Singleton por móduloA config (config_account.ts) é exportada pronta; o sistema de módulos a executa uma vez

  5. 05

    `destroy()`Fecha as conexões e zera a instância, para o shutdown e para os testes não vazarem estado

  6. 06

    Cache-asidebalanceFind lê do cache, cai no banco no miss e grava o saldo com TTL; erro do Redis vira miss

Trade-offs

O que se ganha, o que se paga

3 vantagenscada ganho tem um preço3 custos

Vantagens

  • Uma instância: conexões e memória não se multiplicam

  • Ciclo de vida central (getInstance/destroy)

  • Criação preguiçosa, só quando alguém usa

Custos

  • Estado global: um módulo enxerga o que outro alterou

  • Teste precisa de destroy() entre casos

  • Uma instância por processo ou worker thread, não por cluster

apps/patterns/singleton-pattern

7 arquivos

src/

  • pool_account.tsSingleton do pg.Pool, com getInstance() e destroy()
  • cache_balance.tsSingleton assíncrono do cliente Redis, com leitura fail-open e invalidação
  • config_account.tsConfig validada no boot, singleton por módulo
  • balance_account.tsConsulta de saldo cache-aside sobre os dois singletons
  • pool_account.test.tstesteIntegração contra PostgreSQL e Redis reais: mesma instância, teto de conexões, destroy, corrida no primeiro uso, cache compartilhado
  • demo.tsdemoSingleton contra um pool por chamador e o cache compartilhado entre módulos

./

  • docker-compose.ymlinfraSobe PostgreSQL e Redis

Executar · com Docker

  1. docker compose up -d# sobe PostgreSQL · Redis
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário

Testes: bun run test.

Requisitos
BunDocker
Sobe junto
PostgreSQLRedis

Relações

Onde ele se encaixa

Mapa
  1. Singleton Pattern
  • Combina com2
  • Alternativa a1

Por que se relacionam

Combina com

Alternativa a

Teste rápido

Qual destes combina com Singleton Pattern?

Próximo projeto · Padrões FundamentaisTimeout Pattern
Esc

↑ ↓ navegarEnter abrir191 resultados