O design do sistema Beyou - modelo de domínio, fluxo de dados, fronteiras de segurança e os diagramas por trás de cada decisão.
Como o Beyou roda em produção: quatro superfícies de cliente, uma API Spring Boot, PostgreSQL, um pipeline de imagens saindo do GitHub e o monitoramento que vigia tudo isso.
A produção é um laptop de 2012 em um quarto: Debian 13, Docker, um Cloudflare Tunnel discando para fora e zero portas abertas para a internet.
Prometheus, Grafana, Loki e GlitchTip em um único overlay do Compose: como cada pergunta é respondida, como o coletor avisa um humano e por que tudo é idêntico em dev e produção.
Cada entidade do Beyou: o ciclo central de hábitos, tarefas, metas e rotinas, mais as famílias de histórico, snapshots, feedback e chats de IA construídas ao redor.
A fórmula de XP, a curva quadrática de levels, dois sistemas de streak que só quebram numa falta real, check-ins atrasados com decaimento, o livro-razão diário assinado que torna cada número auditável, e como o fuso da própria conta decide em que dia tudo isso cai.
Autenticação, tokens, rate limiting, checagens de posse, endurecimento de uploads, guarda-corpos do agente de IA e os validadores de boot que recusam uma produção mal configurada.
Um agente de chat com 33 ferramentas reais, transmitido por SSE, rodando sobre uma cadeia de fallback de LLMs configurável, com três camadas de memória e guarda-corpos que assumem que o modelo vai se comportar mal.
Como a camada Caffeine funciona no backend: três tiers de cache, a estratégia de evicção por usuário e sua única exceção global, e os caches que vivem fora do gerenciador do Spring.
Como estas próprias páginas viajam: markdown em um repositório Git, uma importação autenticada para o Postgres, uma API pública e um site estático pré-renderizado que se reconstrói a cada push de conteúdo.
Sete e-mails, uma classe de serviço: seis transacionais e um que ninguém pediu, como cada um se desacopla da transação do banco, os três limites entre um gatilho de nudge e uma caixa de entrada, e por que o remetente sobe desligado.
Dois aspectos dão a cada controller e service logging, medição de tempo e roteamento de erros consistentes, calibrados para erros de cliente ficarem quietos e falhas reais ficarem barulhentas, e cada linha estampada com o id do usuário a quem ela pertence.
Uma base TypeScript, dois clientes: como o web app e o app mobile nativo dividem estado, camada de API, temas, traduções e validação como código-fonte cru, e onde eles deliberadamente se separam.
Como o web app se organiza dentro do monorepo: o shell compartilhado, o quarteto de componentes por entidade, o sistema de widgets, o tutorial em duas partes e o code-splitting que mantém o primeiro carregamento pequeno.
Um pacote de estado dividido entre web e mobile: 17 slices, uma blacklist de persistência ciente de PII, a função compartilhada de aplicar gamificação e a camada HTTP de dois níveis por baixo.
O lado do cliente na fronteira de confiança: tokens em memória, o boot de refresh silencioso, um portão de admin que se recusa a confiar no cliente, persistência ciente de PII e os headers que o nginx serve na frente de tudo.
Dois idiomas e um sistema de tema com duas bases e cinco acentos: pacotes de tokens compartilhados, uma string de preferência mode:pack, acompanhamento vivo do sistema operacional e a migração que aposentou os nove temas antigos.
PostHog em quatro superfícies atrás de um proxy first-party: o vocabulário de eventos nomeado pelos gatilhos de engajamento e não pelos botões, as person properties de que as coortes são feitas, o que nunca sai do browser, e como os adblockers moldaram o transporte.