DEV Community: Ortiz de Arcanjo António David

O CARTEL DE VAGAS EM ANGOLA

Ortiz de Arcanjo António David — Mon, 21 Sep 2026 20:21:08 +0000

Há um CARTEL DE VAGAS em Angola.
Muita gente sabe. Mas prefere calar. Por medo de cancelamento e retaliação.

Mas a verdade é que já tens sofrido a retaliação, já tens sofrido o cancelamento.
Quando passas por todas as fases do processo seletivo e a vaga desaparece.
Quando estás à espera do feedback final e, num instante, vês outros a começarem na vaga que esperas há meses, sem precisão envolvida.

QUEM FORMA O CARTEL?

Grandes bancos
Consultorias famosas
Big Four
Instituições públicas
Empresas médias É praticamente impossível entrar só com capacidade. Sabe por quê? Porque a vaga nunca foi pública.

O "NETWORKING" QUE NÃO É NETWORKING
Em Angola existe um "networking" que, na verdade, é um CARTEL.
As melhores vagas de 1M, 2M, 3M KZ não vão para o LinkedIn.
Não vão para o Emprego.co.ao.
Não vão para lugar nenhum.
Elas vão:

Para o grupo de WhatsApp dos "amigos".
Para o "filho do meu colega".
Para o "sobrinho do diretor". Requisitos? Zero. Portfólio? Ninguém vê. Experiência comprovada? Raramente. Teste técnico? Nem pensar. O único requisito é: Ser dos nossos.

E QUEM FICA DE FORA?
Profissionais com 5, 7, 10 anos de código.
Java, C#, React, Arquitetura, Node.
Que constroem sistemas. Que resolvem problemas.
São ignorados por anos.
Porque não são "do grupo".

OS DEVS ESTÃO CANSADOS
Os devs estão cansados.
Cansados de bater na porta fechada.
Cansados de ver quem não entrega ganhar 3M KZ enquanto quem entrega rala.
Por isso muitos fizeram o que precisava ser feito:
Derrubaram a parede e saíram.

DERRUBARAM A PAREDE
Foram para o empreendedorismo, criaram produtos, arriscaram e deram cara ao desafio de começar uma empresa.
Foram para o mercado global.
Lá não existe cartel.
Lá existe: Código. Entrega. Resultado. Dólar.
Ninguém pergunta "de quem tu és filho".
Perguntam:
"Consegues entregar em 2 semanas?"

A VERDADE DÓI, MAS LIBERTA
Enquanto se depender do cartel local, eles controlam a empregabilidade, salário e motivação profissional.
Quando se vai para o empreendedorismo ou para o mercado global, eles não mandam mais.
Chega de mendigar migalha.
Chega de preço de banana.
Chega de porta fechada.
Chega de fingir que "networking" é meritocracia.

JÁ PASSASTE POR ISSO?
Comenta "CARTEL" se já passaste por isso.
Quero ver quantos foram ignorados.

Na próxima publicação, voltarei aos posts técnicos e falarei sobre Auto-healing numa aplicação Go.

A Culpa não é do teu Currículo

Ortiz de Arcanjo António David — Mon, 14 Sep 2026 18:22:41 +0000

Não é o teu CV.
Não são as tuas habilidades.
Não é falta de soft skills.

É o sistema.

Um sistema viciado. Desenhado para justificar rejeições e criar 100 requisitos ocultos que ninguém cumpre.

A realidade em Angola é esta:

Processos longos e confusos
15 fases. Entrevistas que correm bem. Perguntas técnicas e comportamentais com cenários reais, todas respondidas. E depois... silêncio. Sem feedback.
Candidatos esquecidos
Gente capacitada, com experiência comprovada, que passou em todas as fases e fica 1, 2 anos à espera de retorno.
Entradas rápidas e sem critério
E na mesma vaga, entram pessoas com menos capacidade, menos experiência, sem passar por metade das fases. Em poucas semanas.

Porquê?
Porque a triagem já começou antes do anúncio. Faz parte do teatro.
Os "DELES" já foram escolhidos primeiro.

O que pesa mais que o CV:

Indicações - o famoso QI
Membros da família
Amigos do círculo
Testes de fachada
Rivalidades escondidas
Mal uso da IA para filtrar candidatos. E quem percebe os erros da IA, aproveita.

Pedem "sopa de letras" de requisitos intangíveis. Requisitos que nem o próprio gestor domina.

Tu gastas horas a melhorar o CV com técnicas dadas por RH experiente. E nada funciona.
Porque a culpa não é do currículo. É do sistema.

Já passaste por isso?
Comenta aqui qual foi a fase mais absurda que já enfrentaste num processo seletivo.

Vamos expor isso. Precisamos falar sobre isso.

A Invisibilidade dos devs angolanos

Ortiz de Arcanjo António David — Tue, 08 Sep 2026 14:40:40 +0000

O maior problema dos Devs Angolanos não é técnica. É invisibilidade.

Tive esse debate esses dias e a verdade doeu:

"Nós angolanos somos fechados neste lado"
“Apenas mostram cargos e status”
"Quantos devs que trabalham remoto partilham a experiência??"
"É a praga do 'SE TIREI, SE SAFEI'. Estes têm afundado o bastante."

E é verdade.

Enquanto os indianos mostram resultado e são contratados...
Enquanto os brasileiros fazem 20 webinar, bootcamp, postam código, ensinam de graça só para serem vistos...

Nós ficamos nos grupinhos.
Cada um tentando construir a própria ponte pra atravessar o rio.

Supondo que o problema seja atravessar o rio, é imprudente cada um gastar tempo e dinheiro construindo sua ponte sozinho.

Com colaboração conseguimos construir a ponte e todos passam mais rápido e criamos mais oportunidades para os devs angolanos.

O Dev angolano não vende o peixe. Raramente partilha conhecimento, por mais simples que seja.
Não mostra portfólio. Não tem presença. Não cria reputação.
Resultado: preferem contratar quem aparece.

Se continuarmos a divulgar, a ensinar, a mostrar resultado...
Eles virão atrás dos angolanos também.

Chega de individualismo.
Chega de obsolescência no cantinho.
A partilha pode ser o termômetro para cada um entender em que fase se encontra e qual será a próxima.

Vamos partilhar conhecimento.
Vamos atrair remoto.
Vamos construir a ponte juntos.

Por que contratar um Dev Remoto Angolano?

Ortiz de Arcanjo António David — Tue, 01 Sep 2026 14:06:57 +0000

Enquanto todo mundo disputa os mesmos devs caros nos EUA e Europa, existe um mercado inteiro de talento sendo ignorado: Angola.

Aqui vão 4 motivos reais:

Custo x Qualidade Formação sólida, bilíngue PT/EN, fuso GMT+1. Mesma qualidade técnica, investimento 3x menor. Oportunidade que gera impacto real.
Fome de Crescimento Aqui as vagas são poucas e muito concorridas. Quando um dev angolano recebe uma chance global, ele agarra com as duas mãos e entrega 200%.
Resiliência nível Hard Aprender a programar com poucos recursos te ensina a ser criativo e resolver problema. Qualquer desafio de produto é pequeno perto disso.
Pagamento? Resolvido SWIFT, Wise, Payoneer, Deel. Já não é mais desculpa. O dinheiro chega em USD.

Angola está cheia de talento que só precisa da primeira porta aberta.

Dê essa oportunidade. Você ganha um dev leal, dedicado e com algo pra provar. Nós ganhamos a chance de mostrar nosso valor.

Angola pode ser a nova Índia do desenvolvimento de software.

Aqui existem milhares de desenvolvedores resilientes, criativos e altamente qualificados. Gente que entrega resultado de excelência mesmo com poucos recursos, internet instável e prazos apertados.

A tua empresa pode contratar esse talento hoje.
Mesma qualidade de um dev da Europa/EUA. Custo muito menor. Impacto social gigante.

Dê a primeira oportunidade remota para um desenvolvedor angolano.
A tua empresa contrata talento e consequentemente muda a realidade de uma família inteira.

Trabalho Remoto - Como receber os Pagamentos

Ortiz de Arcanjo António David — Sun, 30 Aug 2026 21:29:08 +0000

Se enumerarmos os fatores que levantam dúvidas e atrapalham o primeiro passo no trabalho remoto, com certeza a forma de Pagamento e Recebimento do salário ocupa o 1º lugar.

A incerteza de como a empresa fará os pagamentos do salário e de como o Desenvolvedor vai receber, afasta as negociações.

Realidade de Angola

No meu caso, Angola não oferece condições para pagamentos internacionais como es da Europa e América, por exemplo. Esse favor coloca Angola fora de do mapa de trabalho remoto.

Há muitos casos em que a empresa opta por outros candidatos de países que facilitam essa transação. No meu caso, perdi e continuo a perder várias oportunidades de emprego, por causa dessa incerteza, desde o jurídico até o financeiro.

Métodos/ Sistemas Conhecidos

WISE
Revoult
Payoneer
USDT
Stripe
Nomes Global

Solução Oficial

A solução mais segura que encontrei foi a transferência internacional por meio do sistema SWIFT.

O que é o SWIFT?

Em poucas palavras: SWIFT é a forma oficial de transferências entre países. Todas transferências comerciais entrar países passam por esse sistema.

Estrutura do SWIFT

O Swift é formado pelo IBAN, Endereço do Banco, Código Swift, Registo Bancário, Contacto do Banco e Endereço do Beneficiário.

Como usar o SWIFT para pagamentos

Solicitar os dados SWIFT no seu banco.
Organizar os dados SWIFT num arquivo PDF ou Imagem
Fornecer os dados a Empresa
O valor chega em dólares, na conta do seu banco comercial
Converter o valor de USD para AOA

Observações

A transferência internacional com SWIFT pode durar de 3 a 5 dias úteis
Necessita de conversão por parte da Empresa, mas é simples
A transferência requer validação de N bancos intermediários e outras instituições
O beneficiário sofre pequenos descontos, totalizando aproximadamente 13 000 AOA

Resultado

No início duvidava desse método.
O primeiro contacto foi estranho pela demora mas ganhei confiança nesse método actualmente é o que mais confio.

Conclusão

O SWIFT pode ser a resposta que as empresas estrangeiras procuram durante o recrutamento de Profissionais Angolanos.
As empresas internacionais podem economizar muito, dando oportunidade aos programadores angolanos.

Exemplo

Em seguida forneço uma imagem com os dados necessários para uma transferência Swift, usando o banco BAI.

Para mais informações, contactar o seu banco pode trazer as melhores respostas.

Minha experiência: 1 ano de Trabalho Remoto

Ortiz de Arcanjo António David — Sun, 16 Aug 2026 21:59:30 +0000

Como começou

Em junho de 2025 comecei a trabalhar remotamente como Backend Engineer.
Stack: Python, MongoDB e Redis para o desenvolvimento de uma plataforma administrativa multi-organizações, focada no setor jurídico e com expansão para RH e financeiro de cada cliente.

3 meses depois ingressei em outra oportunidade como Golang Developer, desenvolvendo microsserviços para diferentes produtos: motor de assinatura de documentos, serviço de log e auditoria de sistemas, gestão completa de produtos e até controle de frota com autenticação OTP.

Depois de 1 ano trabalhando ativamente e de forma deliberada com a cultura remota, adquiri experiências que serão úteis em qualquer oportunidade. Acredito que é o formato que mais se identifica comigo: foco, testar, corrigir e entregar.

O que esses trabalhos têm em comum: orientação a resultado. São muitas demandas e todos os sistemas têm um requisito básico: multi-tenant. Eu já tinha noções sobre o tema, mas aprendi na prática a lidar com a complexidade de isolar dados sem vazamento entre organizações.

Evolução

Anteriormente eu tinha uma má impressão sobre o trabalho remoto. Como seria avaliado? Como mostrar resultados? Como ficariam as interações?
Com o tempo, essas questões se tornaram fáceis para mim.

Remoto não é desvantagem. Apenas exige um tempo de adaptação, tanto para a empresa quanto para o profissional.
Quem ingressa no remoto e colhe bons resultados, raramente deseja voltar ao formato 100% presencial.

Comparação com o presencial

O formato presencial é bom: há interações pessoais cara a cara, confraternizações, facilidade para explicar inquietações aos líderes e agilidade no dia a dia. Mas, felizmente, a área de software nos dá a possibilidade de trabalhar remoto e entregar mais resultados, abrindo mão apenas da interação pessoal.

Pontos fortes

Orientação a resultado
Eficiência
Reuniões mais curtas
Sem conversas paralelas
Obriga a automatizar processos de desenvolvimento

Desafios

Cobrança maior, pela falta de outros elementos de acompanhamento
Risco de acúmulo de tarefas em pouco tempo
Pouca interação pessoal, o que pode ser um problema para alguns
Questões documentais podem ser menos rigorosas

Conclusão

Espero permanecer por muitos anos trabalhando remotamente.
Tem sido satisfatório trabalhar nesse formato, de qualquer lugar, entregando resultados com pouca burocracia.

Como implementar No-Ops para Blindar Microsserviços em Go

Ortiz de Arcanjo António David — Tue, 12 May 2026 13:52:29 +0000

Muitas aplicações morrem (panic) porque um serviço de telemetria ou um broker de mensagens ficou offline por apenas 5 segundos.
Por que é que a minha API de vendas caiu se o problema foi no servidor de logs, de cache ou de tracing?

O sistema em produção deve resistir em caso de falha de infraestrutura. Para isso, basta definirmos prioridades e criticidade de acordo com o contexto da aplicação.

Conceitos-Chave

Fail Fast: Para a Database. Se não há dados, não há negócio. Trava o processo cedo.
Fail-Safe / Graceful Degradation: Para Observabilidade e serviços auxiliares. Se o Tracing caiu, a vida continua.
Null Object Pattern (No-Op): A técnica de implementar interfaces com métodos vazios (ou neutros) para evitar verificações de if resource != nil constantes no código de negócio.

Anatomia da Blindagem

A nossa estrutura de InfrapResources deve ser inteligente ao inicializar os contratos:

Hard Dependencies: Aquelas que definem o estado (ex: Postgres para transações, Redis para Auth).
Soft Dependencies: Aquelas que auxiliam o sistema (ex: RabbitMQ para eventos assíncronos, Prometheus, OpenTelemetry).

Base para a Implementação

A base da nossa resiliência reside na Programação por Contratos. Ao definirmos interfaces claras em ports, permitimos que a aplicação decida, em tempo de boot, qual "peça" encaixar:

A peça Real: Conecta ao serviço e executa operações reais.
A peça No-Op: Silencia falhas e mantém o sistema estável (executa uma operação "vazia").

Ambas respeitam rigorosamente os contratos de infraestrutura: Database, Cache, MessageBroker, entre outros.

Benefícios Reais

Developer Experience (DX): O programador não precisa de espalhar if r.Resource != nil em todo o lado. O contrato está lá e é seguro chamá-lo.
Resiliência: A app sobrevive em ambientes instáveis (como instâncias gratuitas ou clouds com flutuações de rede).
Testabilidade: No-Ops são, na prática, Mocks prontos para testes de integração e desenvolvimento local rápido.

Conclusão

Muita gente confunde resiliência com 'nunca falhar'. Na verdade, resiliência é saber o que fazer quando a falha acontece.
Implementar No-Ops em Go é uma das formas mais elegantes de garantir que o teu sistema não entra em pânico por causa de uma dependência não-crítica

Código Fonte:

https://github.com/ortizdavid/golang-pocs/tree/main/resilience

Gerenciamento de Cron Jobs em Golang

Ortiz de Arcanjo António David — Fri, 24 Apr 2026 15:02:56 +0000

Dando continuidade à nossa série sobre tarefas em segundo plano, hoje vamos focar em algo que todo o sistema robusto precisa: Cron Jobs.

Muitas vezes, precisamos executar uma tarefa em intervalos específicos: a cada 30 minutos, 15 segundos, ou a cada 2 horas.

Recapitulando: Worker vs Cron Job

Embora ambos rodem em background:

Worker: Foca no processamento contínuo (ex: consumir uma fila até que ela fique vazia).
Cron Job: Foca na recorrência agendada (ex: gerar um relatório de 15 em 15 minutos).

Exemplos comuns de Cron Jobs

Limpeza de arquivos temporários: Evitar que o disco fique cheio com logs antigos.
Relatórios de Negócio: Consolidar vendas do dia anterior.
Sincronização de Dados: Atualizar taxas de câmbio ou stocks de APIs externas.
Backup de Segurança: Realizar dumps periódicos de tabelas críticas.

O problema da falta de orquestração

Quando começamos a criar vários jobs espalhados pelo código, o problema aparece rápido:

Visibilidade: Quais tarefas estão ativas agora?
Resiliência: Se uma tarefa entrar em "panic", ela vai derrubar toda a minha API?
Encerramento Limpo: Se eu desligar o servidor, as tarefas param no meio do caminho corrompendo dados?

A solução é simples: um Cron Job Manager.

Passos para criação do Cron Job Manager

Definir uma Interface: Padronizar as operações necessárias, com nome, um tempo de agendamento e o método de execução.
Implementar o Engine com Tickers: Usar time.NewTicker para intervalos regulares.
Isolamento de Erros (Recover): Capturar e logar erros sem interromper o Manager.
Contexto de Cancelamento: Propagar o context.Context para que todas as Goroutines respeitem o sinal de paragem do sistema.

Vantagens desta Arquitetura

Graceful Shutdown: recebe o sinal de cancelamento do Sistema Operativo e avisa os jobs para terminarem as suas operações de forma segura.
Desacoplamento: O motor do Cron não conhece a regra de negócio; ele apenas executa "contratos".
Observabilidade: Centralização de logs, permitindo rastrear o início e o fim de cada operação.
Plug and Play: Adicionar um novo job é simples. Basta registarmos no Manager.

Código fonte: https://github.com/ortizdavid/golang-pocs/tree/main/cronjob-manager

Gerenciamento de Workers numa aplicação Golang

Ortiz de Arcanjo António David — Mon, 06 Apr 2026 14:02:04 +0000

Atualmente é indispensável que um sistema que cresce esteja preparado para processar tarefas em background.
Essas tarefas não devem interromper o fluxo normal da aplicação.
O melhor é estruturar como esses workers vão se comportar e permitir a configuração dos mesmos.

Felizmente, Golang nos dá a vantagem de criar estruturas que facilitam esse tipo de aplicações.
Usando Goroutines, channels e contextos de cancelamento, conseguimos criar essa estrutura.

Cron jobs VS Workers

Facilmente confundimos Cron Jobs com Workers. Eles partem do mesmo princípio de executar tarefas em segundo plano.

Worker: processa tarefas num ciclo infinito, usando a frequência e número de tentativas.
Cron Job: trabalha com agendamento, a tarefa é somente executada no tempo definido.

Exemplos mais comuns de Workers

Processamento de uma regra de negócio
Envio de dados para uma fila
Consumo e processamento de filas
Envio de e-mails recorrentes
Campanha de mensagens em massa
Envios de SMS

O problema de muitos workers

Quando a aplicação cresce, podemos ter várias tarefas por processar na aplicação.
Encadear cada tarefa torna o código difícil de ler e manter. Nesse caso, devemos achar uma estratégia para organizar e manter esse número de workers.
A forma mais elegante é o worker manager, organizador e orquestrador de workers, responsável pelo registro, chamada e ciclo de vida dos mesmos.

Passos para criação do Worker Manager

Definir uma interface para a base dos workers: Start, Stop e Worker Name
Criar o manager que agrupa os workers
Criar um mecanismo para iniciar e parar todos os workers
Se necessário, uma função para mostrar as infos dos workers registrados no sistema
Configurar o máximo de tentativas e o intervalo de tempo que os workers vão executar a operação

Vantagens

Graceful shutdown: o manager avisa a todos os workers quando parar. Eles não perdem dados, escutam o sinal de cancel e vão parando.
Estratégias de backoff
Modularidade
Código fácil de manter e evoluir
Arquitetura plug and play

No futuro veremos como implementar um cron job manager.

Código fonte: https://github.com/ortizdavid/golang-pocs/tree/main/worker-manager

Por que o seu Microserviço deve permitir Integração via JSON-RPC?

Ortiz de Arcanjo António David — Tue, 17 Mar 2026 17:48:02 +0000

Embora o REST seja o padrão absoluto para o Frontend, a comunicação entre serviços (Service-to-Service) pede algo mais direto e menos verboso.

O gRPC é frequentemente citado como a solução de elite, mas traz uma complexidade de infraestrutura (.proto, geração de código, HTTP/2) que muitos projetos não precisam no dia zero.
O JSON-RPC surge como o "pote de mel": simples como JSON, mas eficiente e intuitivo como uma chamada de função local.

Onde cada um brilha?

REST: Perfeito para recursos públicos. Focado em substantivos (/users).
gRPC: Ultra-performance e streaming. Focado em contratos rígidos (Binário).
JSON-RPC: O melhor para comunicação interna ágil. Focado em ações (User.Create). É nativo em Go e não exige ferramentas externas.

Implementação Enterprise: O que não pode faltar

Para um sistema robusto, não basta apenas "rodar" o RPC. É preciso controle:

Capabilities: O serviço deve ser capaz de se "auto-apresentar", listando métodos disponíveis via reflexão no arranque.
Rastreabilidade: Cada chamada deve carregar um Trace-ID no Contexto para que saibas exatamente quem iniciou a cadeia de ações.
Segurança (Internal Key): Autenticação rápida via Headers (X-Internal-Key) para garantir que apenas serviços autorizados acedam ao motor RPC.

O Desafio da Memória em Go

Um detalhe crítico ao implementar RPC em Go com transações de base de dados: Cuidado com a estabilidade dos ponteiros.

Ao usar closures (funções anónimas) dentro de transações, evita declarar ponteiros nulos para o retorno. Se tentares preenchê-los apenas dentro da transação, podes enfrentar problemas de visibilidade de memória (Race Conditions) que resultam em nil pointer dereference.

A Boa Prática: Inicializa sempre a tua struct de resposta (new(Struct) ou &Struct{}) antes de entrar na transação. aIsso garante um endereço de memória estável e evita que o teu Dispatcher RPC sofra um Panic.

Configurações e Limites

Um motor RPC robusto precisa de fronteiras claras:

Timeouts: Controle rígido para que uma chamada não "prenda" o serviço infinitamente.
Payload Limit: Evita que requisições gigantes saturem a memória do servidor.
Observabilidade: Logs automáticos de cada método invocado, incluindo a latência e o status da resposta.

Conclusão

Adotar JSON-RPC na arquitetura interna reduz o overhead de roteamento, facilita o debug (é legível, ao contrário do gRPC) e mantém o código limpo.
É a escolha de quem prefere resolver problemas de negócio a lutar contra a infraestrutura.

O JSON-RPC dá ao teu sistema a fluidez de uma chamada de função com a robustez de um microserviço.

Minha experiência com gRPC e Golang: Construindo um Motor de Assinatura Digital

Ortiz de Arcanjo António David — Wed, 04 Mar 2026 10:25:37 +0000

Nas últimas duas semanas, aceitei um desafio técnico intenso: desenvolver um microserviço de assinatura digital utilizando Go e gRPC.
Foi um projeto que me tirou da zona de conforto (resolver problemas de negócio puros) e me mergulhou profundamente em engenharia de infraestrutura e criptografia.

O Desafio Técnico

O objetivo era criar um motor de processamento capaz de receber documentos financeiros em XML, realizar o parse, garantir a integridade via algoritmos de assinatura digital e retornar o documento assinado de forma única.
Tudo isso com foco em alta performance e disponibilidade.

Stack de Engenharia

Para suportar essa complexidade, utilizei uma stack robusta:

Go & gRPC: Escolhidos pela necessidade de baixa latência e comunicação eficiente machine-to-machine (evitando o overhead do JSON/REST).
HashiCorp Vault: Gestão segura de segredos e chaves privadas (Secret Manager).
MinIO: Armazenamento de objetos para os arquivos de certificados (.pfx).
MySQL & Redis: Persistência de metadados e camada de cache para otimização de consultas.
Criptografia X.509: Lógica para extração de metadados e validação de cadeias de confiança.

Destaques de Implementação

A arquitetura foi pensada para garantir a idempotência e a segurança em repouso, pilares fundamentais em sistemas que lidam com documentos financeiros sensíveis.

Segurança Multitenant: O sistema permite que cada consumidor gerencie seu próprio certificado, isolado e protegido por criptografia através do Vault.
Performance: Sem interface gráfica e focado em processamento pesado, o gRPC garantiu que múltiplos sistemas pudessem consumir o serviço simultaneamente com estabilidade.
Cultura de Testes: Para validar a resiliência, desenvolvi scripts de automação em Bash e utilizei o grpcurl para testes de stress, simulando múltiplos clientes em simultâneo.

O Aprendizado

A grande conclusão prática é que o gRPC é a escolha de excelência para integração entre sistemas onde estabilidade e processamento pesado são inegociáveis. Trabalhar com criptografia e certificados digitais é uma área complexa, mas extremamente gratificante quando vemos os resultados de performance validados na prática.

Mais um conhecimento adquirido e pronto para ser aplicado em soluções de escala global!

Como implementar Injeção de Dependências em Go manualmente?

Ortiz de Arcanjo António David — Mon, 23 Feb 2026 17:13:19 +0000

A linguagem Go permite controlar manualmente as dependências com mais facilidade.
Cada item da sua aplicação pode ser instanciado onde o desenvolvedor desejar. Go nos dá essa liberdade.

Mas, com o crescimento do projeto, é importante arranjar uma estratégia para carregar as dependências, porque elas podem afetar positiva ou negativamente a aplicação.
Essa liberdade do Go pode dar margem para vários erros de dependências. Para projetos pequenos, faz sentido, mas para grandes projectos pode ser difícil de manter.

Cenário comum: main inflado

Instanciar DB, cache, configs no main
Instanciar repos, services
Criação e inicialização dos componentes Isso Faz sentido para projetos com poucos componentes, não reprsenta grandes riscos.

Solução: injeção via containers

Criar container de infraestrutura: DB, Cache, Logger, Mensageria e outros.
Container de serviços: regras de negócio
Container de repositórios: interação com a base de dados No Main, só precisamos carregar os containers. o Main se torna o maestro da aplicação.

Vantagens

Criação dos objetos 1 vez apenas
Organização dos componentes
Separação de responsabilidades
Performance melhorada

Por que fazer isso manualmente?

Embora existam bibliotecas como Google Wire ou Uber FX, fazer a gestão manual com containers traz:

Performance: Sem uso de reflection em tempo de execução.
Transparência: Você vê exatamente o que está sendo injetado e onde.
Singleton por Design: Objetos pesados (como pools de DB) são criados apenas uma vez.
Testabilidade: É fácil substituir um repositório real por um mock nos seus testes.

Código-fonte

Como tens organizado as dependências nos teus projetos? Abordagem manual ou usas bibliotecas?