Introdução
Overview
Esta é a documentação técnica interna do AZ Collections. Ela existe para apoiar o desenvolvimento e as atualizações da plataforma — registrar o que está construído, o que está devendo e o que precisa acontecer a seguir.
Conteúdo
Seis seções. Duas olham para o que existe e o que ele custa, três explicam como as peças funcionam por dentro, e uma olha para frente.
| Seção | Responde | Quando consultar |
|---|---|---|
| Overview | O que é esta documentação e como os serviços se dividem. | No primeiro dia, ou para lembrar quem é dono de quê. |
| Débitos técnicos | O que hoje custa tempo, dinheiro ou risco — e por quê. | Ao planejar sprint, priorizar refatoração ou entender por que algo é lento de mexer. |
| Infraestrutura | Visão geral (consumo e arranjo de servidores); APIs — Core, AZ Chat, AZ Dash, AZ Media e Testes de carga; Analytics; Rede e banda; Segurança. | Ao dimensionar servidores, entender como um serviço funciona de ponta a ponta, medir o app ou corrigir uma falha de segurança. |
| Dashboard | O que o painel administrativo faz, tela a tela, e o que ainda falta nele. | Ao operar o painel, investigar um número dele ou planejar uma tela nova. |
| Features | Sorteios e Convites — como cada um funciona, no app, no painel e no código. | Ao mexer numa dessas funcionalidades ou responder dúvida da equipe sobre elas. |
| Próximos updates | O que vem a seguir — gamificação, autenticidade, chat e busca —, lido contra o código. | Ao priorizar a próxima frente ou estimar o que já está no chão. |
Contagem de arquivos, tamanho de serviços, versões de biblioteca e cobertura de tabelas foram medidos no código, não estimados. Afirmações sobre ambiente valem para a data indicada — ambiente muda, e memória envelhece.
Como a plataforma se divide hoje
O AZ Collections é um aplicativo e cinco serviços. Saber quem é dono de quê evita a confusão mais comum aqui — procurar uma funcionalidade no lugar errado.
| Serviço | Repositório | Host | De que é dono | Estado |
|---|---|---|---|---|
| Aplicativo | frontend.azcollections.mobile |
App Store e Play Store | Toda a interface. React Native / Expo. | Nas lojas (3.0.x) — 3.0.1 desde setembro de 2026; a 3.0.4 prestes a sair |
| Servidor principal | api.azcollections.backendcore |
api.collectionsaz.com |
Identidade e contas, feed, coleções, busca, loja, checkout, pedidos, notificações, AZ Pay, sorteios e convites — e o hub de eventos, que mantém as projeções dos outros serviços para o app ver tudo numa lista só. | Em produção |
| Chat | api.azcollections.chat |
chat.collectionsaz.com |
Conversa, negociação e propostas de troca. | Em produção desde 27/08/2026, com banco dedicado |
| Mídia | api.azcollections.media |
az-media.collectionsaz.com |
AZ Play (vídeo, engajamento e feed próprio), envio de fotos e vídeos, moderação automática. | Em produção desde 22/08/2026 |
| Dashboard | api.azcollections.dashboard |
PM2 na box az-prod |
Administração interna, relatórios e observabilidade. | Em produção |
| Webhook do Stream | az-stream-webhook-dispatcher |
Cloudflare Worker | Replica o webhook do Cloudflare Stream para produção, staging e dev. | Em produção |
Os repositórios foram renomeados em 28/08/2026 para o padrão
<tipo>.azcollections.<serviço>; os domínios de produção
não mudaram. Nome de repositório não é host.
Entre os backends, a conversa é por eventos no RabbitMQ (a exchange
collections.events, com idempotência por eventId), não por chamadas
diretas: cada um mantém sua própria cópia do que precisa saber dos outros. É o que permite que
um fique fora do ar sem derrubar os demais — e também o que explica por que um dado às vezes
demora alguns segundos para aparecer em outro lugar. Já o aplicativo chama
cada serviço direto, no dono do domínio — reel no media, conversa no chat, o resto no core. E
o dashboard lê o banco do produto direto (a réplica de leitura existe no
código, mas produção ainda não tem uma) e passa a escrever pelo core, via HTTP — categorias,
anúncios e sorteio já fazem assim; o resto ainda escreve direto no banco.
Por onde começar
Para quem chega agora ao projeto, Débitos técnicos é a leitura mais curta e a que mais explica o comportamento do código: por que certas áreas são lentas de alterar, onde estão as armadilhas e o que já se sabe que precisa mudar.
Para entender um serviço por dentro, o ponto de partida é a página dele em Infraestrutura → APIs.