DEV Community: Ortiz de Arcanjo António David

Breakdown de Cálculos: A Fórmula que Conta a Própria História

Ortiz de Arcanjo António David — Wed, 14 Oct 2026 00:14:46 +0000

Algumas regras de negócio não são só código. São fórmulas.
Fórmulas complexas, agregações pesadas, fórmulas que contam a história de um processo inteiro.

Na maioria dos casos, a regra pode estar certa. Está no papel e está na classe de negócio. Mas onde estão os passos?

A prática comum é guardar apenas o resultado final.
O certo é guardar os passos até ao resultado: a fórmula com cada parte, os operadores, os valores intermediários e descrições relevantes.

Qual é a solução?
Breakdown de Fórmulas.

Conceito

Em vez de o sistema guardar somente total = 5000, ele guarda o processo completo. Essa técnica torna-se a única fonte da verdade.
Cada parte do sistema pega no que precisa desse breakdown: uma parte vai para a BD, outra é libertada no front, outra alimenta o fluxo de negócio.
Podemos até disponibilizar endpoints de simulação para pré-visualizações, sabendo que será sempre o mesmo cálculo final.
Esta fonte organizada pode servir para vários consumidores.

Passos

Decompor: Quebre a fórmula em passos atómicos e auditáveis. Base + Taxa - Desconto = Total não é 1 cálculo, são 3 passos.
Estruturar: Cada passo tem Label, Formula, Valor e Descrição. Não só números.
Centralizar: Uma única função pura retorna o Breakdown completo. Front, Back e relatórios consomem o mesmo objeto.
Expor: O front usa o breakdown para criar experiências interativas. O utilizador não vê só o total, vê como chegou lá.

Onde usar

Formulário de crédito
Formulário de vendas
Emissão de fatura com vários itens
Simuladores (velocidade, aceleração, juros)

De dashboards com indicadores bonitos até formulários onde o cálculo é feito dinamicamente.

Conclusão

Cálculo bom não é o que só acerta no resultado. É o que se explica sozinho.
Quando a sua fórmula guarda a própria história, ganha transparência para o negócio, auditabilidade para o CTO e confiança para o cliente.
Pare de guardar totais. Comece a guardar histórias.

Código Fonte:

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

10 anos de PHP

Ortiz de Arcanjo António David — Mon, 05 Oct 2026 15:51:06 +0000

Este ano completei 10 anos de experiência com a linguagem PHP.

O meu primeiro sistema REAL não foi em Go. Foi em PHP procedural.

2016. 3º ano da faculdade. Projeto de bacharelado: Sistema de Gestão de Museu.

Eu estava viciado em C e C++. C e Assembly para Arquitetura de Computadores, e C++ para Estrutura de Dados e Algoritmos 1 e 2. Ponteiros, listas ligadas, filas, pilhas, árvores e grafos, tudo feito à mão.

Em paralelo, aprendia Java e Orientação a Objetos na cadeira de Programação 2, além de Prolog e Haskell em Programação Declarativa.

Mas o projeto do museu pedia outro nível: levantamento de requisitos, análise, diagramas UML, base de dados, interface gráfica, gestão de utilizadores...

A solução mais rápida? PHP + MySQL.

Foi ali que a ficha caiu. Pela primeira vez, eu não estava só a programar. Eu estava a ser Engenheiro de Software.

O PHP serviu de ponte para o próximo nível de aplicações (do 3º ao último ano): sistemas que lidavam com interfaces gráficas, perfis de acesso, persistência de dados, refinamento de requisitos funcionais e não funcionais, e a tradução direta de regras de negócio em código.

Isso explodiu-me a mente:
Requisito -> Documentação -> Modelação -> Base de Dados -> Implementação -> Apresentação.

E não parei mais.

2017 - 2018: Aperfeiçoei os conhecimentos em PHP Orientado a Objetos e arrisquei criar um ORM próprio para manipular bases de dados — um trabalho que evoluiu ao longo dos anos.
2019 - 2023: Desenvolvi mais de 30 sistemas em PHP e MySQL. Sistemas reais que geriam negócios, freelancers académicos, plataformas de gestão, de tudo um pouco.

O PHP deu-me o que a faculdade muitas vezes não dá: visão de ponta a ponta e orientação a projetos. Foi graças a ele que me destaquei.

Em 2023 migrei para Go em busca de máxima performance e arquitetura. Mas até hoje mantenho projetos pessoais em PHP. E agora, sigo a criar duas novas ferramentas para retribuir à comunidade: o LiteTable e o VeloxRouter.

Obrigado, PHP. Tu não foste apenas uma linguagem. Foste a minha verdadeira escola de engenharia.

E tu? Qual foi o teu primeiro sistema real? Ainda te lembras? 👇

Como implementar Auto-Healing para Blindar Microsserviços em Go em Infra Volátil

Ortiz de Arcanjo António David — Thu, 01 Oct 2026 19:02:25 +0000

Muitas aplicações precisam de restart manual porque o Redis, Postgres ou RabbitMQ ficou offline por apenas 30 segundos. Por que é que preciso acordar às 3h da manhã para dar restart na API se a infra já voltou?
O sistema em produção deve se curar sozinho. Para isso, precisamos de um mecanismo que tente reconectar dependências perdidas sem derrubar o processo principal.

Conceitos-Chave

Self-Healing: Capacidade da app detectar uma dependência morta e tentar reviver sozinha.
Exponential Backoff / Ticker: Intervalos controlados para varredura contínua sem saturar a rede.
Hot-Swap de Dependência: Trocar em runtime uma implementação No-Op por uma Real quando o serviço volta.

Anatomia da Blindagem

O nosso InfraResources não deve apenas iniciar uma vez. Ele deve vigiar continuamente os recursos e realizar a troca dinâmica de forma concorrente em background, utilizando goroutines isoladas e proteção via sync.RWMutex para evitar condições de corrida (race conditions).

Base para a Implementação

A base continua sendo a Programação por Contratos. Como já temos interfaces e implementações No-Op, o ciclo de auto-healing valida o estado atual através de verificações de Ping com timeout controlado, aplica o fallback automático caso a conexão falhe, ou executa o hot-swap transparente para o cliente real assim que o serviço se estabiliza.

Benefícios Reais

Zero Ops de madrugada: A app se recupera sozinha de quedas de rede em clouds gratuitas ou instáveis.
Sem K8s: Resiliência a nível de aplicação, sem precisar de orquestrador externo.
Degradação Elegante: O sistema funciona sem cache/fila até eles voltarem, em vez de morrer.

Conclusão

Muita gente acha que alta disponibilidade é ter Kubernetes. Na verdade, é fazer sua app saber viver sem e se curar quando a dependência volta. Implementar Auto-Healing com No-Ops é como dar um sistema imunológico para seu microsserviço em Go.

Código Fonte:

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

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