A Wave, empresa avaliada em US$ 1,7 bilhão e composta por 70 engenheiros, vem se destacando no cenário tecnológico com sua aplicação CRUD de manipulação de números. Com uma arquitetura padrão CRUD baseada em Python e Postgres, a simplicidade tem sido a chave para escalar suas operações, mantendo o foco em agregar valor aos usuários.

A história da Stackoverflow, que expandiu seu monólito e foi adquirida por US$ 1,8 bilhão, ilustra bem como sites com alto tráfego podem se beneficiar de arquiteturas simples. Apesar de a Wave ser um aplicativo móvel e não depender tanto de tráfego web, sua presença online ainda marca posição entre os 75 mil sites mais acessados, segundo a Alexa.

Curiosamente, enquanto as arquiteturas simples provam sua eficácia, as complexas tendem a dominar as conferências de tecnologia. Por exemplo, em um recente evento de tecnologia, houve uma proliferação de palestras sobre microserviços e arquiteturas complexas, enquanto os monólitos simples não receberam atenção. Essa preferência também é vista em conferências voltadas para empresas, onde há um número significativo de palestras sobre as complexidades das arquiteturas sofisticadas em detrimento dos monólitos simples.

Na Wave, optamos por manter a arquitetura o mais simples possível, evitando o uso de programação assíncrona, que anteriormente nos trouxe mais problemas do que benefícios. Em vez disso, utilizamos o Python síncrono e delegamos tarefas de longa duração a uma fila para não bloquear as respostas.

À medida que nos expandimos para países como Uganda, enfrentamos desafios como a necessidade de operar centros de dados locais para cumprir com as regulamentações de residência de dados. Embora não seja uma operação simples, é menos complexa do que seria com uma arquitetura de serviços sofisticada.

Outro aspecto importante é a decisão entre construir ou comprar software. Apesar de inicialmente termos optado por comprar, eventualmente nos vimos obrigados a desenvolver ferramentas próprias quando os fornecedores não atendiam às nossas necessidades críticas.

Reconhecemos que algumas escolhas técnicas, como o uso de RabbitMQ, Celery, SQLAlchemy e Python, podem ser questionadas, mas até o momento, seus benefícios superam as desvantagens. Em contrapartida, estamos satisfeitos com o uso de GraphQL em nossa API, que oferece vantagens como autodocumentação e a exploração interativa com GraphiQL, apesar de algumas limitações iniciais.

No gerenciamento de hosts, o Kubernetes foi uma escolha acertada, preparando-nos para futuras expansões que exigem operações locais devido a regulamentações.

Por fim, em relação às integrações com telecomunicações, embora a ideia seja usar um provedor SaaS para SMS, as limitações de operação e custos na África nos levaram a desenvolver soluções próprias, que se mostraram justificáveis financeiramente.

Mantendo a arquitetura de nossa aplicação simples, conseguimos alocar nossos recursos em áreas que realmente necessitam de complexidade e agregam valor ao nosso negócio. A filosofia de manter a simplicidade a menos que haja uma forte razão para adicionar complexidade nos permitiu construir um negócio robusto com uma equipe enxuta, mesmo no desafiador mercado financeiro africano.

Agradecimentos a Ben Kuhn, Sierra Rotimi-Williams, June Seif, Kamal Marhubi, Ruthie Byers, Lincoln Quirk, Calum Ball, John Hergenroeder, Bill Mill, Sophia Wisdom e Finbarr Timbers por seus comentários, correções e discussões.