Disclaimer
Este texto foi inicialmente concebido pela IA Generativa em função da transcrição do episódio do nosso canal, Dev Eficiente. Se preferir acompanhar por vídeo, é só dar o play.
Introdução
A Stripe, uma das gigantes no setor de gateways de pagamento, passou por uma evolução significativa ao longo dos anos. O que começou como uma solução simples para processar pagamentos com cartão de crédito nos Estados Unidos, se transformou em uma API robusta, capaz de lidar com uma variedade de métodos de pagamento ao redor do mundo. Neste post, vamos explorar essa jornada de evolução, os desafios enfrentados e as soluções encontradas pela equipe da Stripe.
O Início: Simplicidade e Foco no Cartão de Crédito
A Stripe começou com um foco claro: facilitar o processamento de pagamentos com cartão de crédito. A simplicidade era a chave. A API inicial permitia que desenvolvedores realizassem pagamentos com apenas uma chamada, recebendo uma resposta imediata sobre o sucesso ou falha da transação. Isso era ideal para o cenário de pagamentos com cartão de crédito, onde fazia todo sentido realizar um processo síncrono.
No entanto, à medida que a Stripe começou a expandir seus serviços, novos desafios surgiram. A introdução de métodos de pagamento como o ACH Debit e o Bitcoin trouxe a necessidade de lidar com processos assíncronos, onde o pagamento não era concluído imediatamente. Isso exigiu uma mudança significativa no design da API.
O Desafio dos Pagamentos Assíncronos
Com a adição de novos métodos de pagamento, como o ACH Debit e o Bitcoin, a Stripe enfrentou seu primeiro grande desafio de design. Diferente dos pagamentos com cartão de crédito, esses novos métodos exigiam um processamento assíncrono. No caso do ACH Debit, o pagamento poderia levar dias para ser concluído, enquanto o Bitcoin introduzia ainda mais complexidade, com a necessidade de múltiplos passos intermediários.
Para lidar com essa complexidade, a Stripe precisou introduzir novas abstrações em sua API. Um exemplo disso foi a criação do "Bitcoin Receiver", uma entidade responsável por gerenciar o fluxo de pagamento específico do Bitcoin. Essa mudança foi um marco importante na evolução da API, pois mostrou que a Stripe estava disposta a adaptar seu design para acomodar novos cenários de pagamento.
A Necessidade de Refatoração
Com o tempo, a equipe da Stripe percebeu que o design original da API não era mais suficiente para suportar a crescente variedade de métodos de pagamento. A API, que inicialmente foi projetada para lidar com pagamentos síncronos, começou a mostrar sinais de desgaste à medida que novos métodos de pagamento foram adicionados.
Nesse ponto, a equipe tomou uma decisão importante: era hora de repensar o design da API. Eles perceberam que não poderiam continuar adicionando "remendos" ao design existente. Em vez disso, decidiram criar uma nova arquitetura, separando os conceitos de "Payment Intents" e "Payment Methods". Essa separação permitiu que a API fosse mais flexível e capaz de lidar com diferentes tipos de pagamento de maneira mais eficiente.
A Importância do Conhecimento do Domínio
Um dos pontos mais interessantes dessa jornada de evolução é como o conhecimento do domínio influenciou o design da API. À medida que a equipe da Stripe foi entendendo melhor as nuances dos diferentes métodos de pagamento, eles foram capazes de propor soluções mais adequadas para os problemas que estavam enfrentando.
Esse processo de aprendizado contínuo é algo que ressoa com as ideias do Domain Driven Design (DDD). Na chamada para "estratégica" do livro, é citado que o aprofundamento no domínio te permite realizar refatorações que vão além da organização do código do ponto de vista puramente técnica. A ideia é que conhecendo mais sobre o problema em si, sejamos capazes de organizar o código de tal maneira que represente este novo momento de entendimento.
No caso da Stripe, o conhecimento profundo sobre os diferentes métodos de pagamento permitiu que a equipe criasse uma API que não apenas suportava os métodos de pagamento existentes, mas também estava preparada para acomodar novos métodos que surgiriam no futuro.
A Experiência do Usuário como Prioridade
Outro aspecto fundamental da evolução da API da Stripe foi a preocupação constante com a experiência do usuário. A equipe da Stripe estava sempre atenta à forma como os desenvolvedores interagiam com a API e buscava maneiras de tornar essa interação o mais simples e intuitiva possível.
Um exemplo disso foi a introdução de uma solução chamada "Convenient Packaging of the API". Essa solução permitia que desenvolvedores realizassem pagamentos de maneira mais simples, sem a necessidade de configurar endpoints adicionais para lidar com processos assíncronos. Isso foi especialmente útil para empresas que só queriam processar pagamentos com cartão de crédito de maneira síncrona, sem a complexidade adicional de lidar com callbacks e endpoints.
Design centrado realmente na pessoa usuária
Quando pensamos em design de código, muitas vezes, pensamos na aplicação dos princípios que permitem escrever um código supostamente mais fácil de ser mantido e tudo mais.
Só que design, pelo menos para mim, vai além. Design tem a ver com a experiência que você quer prover para quem vai usar seu produto. Do ponto de vista da Stripe, a API é um produto e quem vai utilizar é uma pessoa desenvolvedora.
Precisa existir uma preocupação constante em fornecer uma experiência de uso da API que facilite muito a vida da pessoa dev. Isso passa por pensar bem nos parâmetros que são obrigatórios, quantidade de endpoints, número de passos para realizar algum fluxo etc.
Conclusão: Evolução Contínua e Adaptação**
A história da API da Stripe é um exemplo claro de como a evolução de um produto está diretamente ligada ao aprendizado e à adaptação. À medida que a Stripe foi entendendo melhor os desafios do mercado de pagamentos, ela foi capaz de ajustar seu design para oferecer uma solução mais robusta e flexível.
No entanto, essa evolução não foi sem desafios. A equipe da Stripe precisou tomar decisões difíceis, como refatorar completamente o design da API, e aceitar que algumas das escolhas feitas no passado não eram mais adequadas para o presente. Mas, no final, essas decisões permitiram que a Stripe continuasse a crescer e a oferecer uma API que atende às necessidades de desenvolvedores ao redor do mundo.
Este é o tipo de decisão que, muitas vezes, empresas deixam de tomar. Perceber que seu negócio está crescendo é massa e, obviamente, ninguém quer perder timing. Ao mesmo tempo, o crescimento deixa nítido que existe um futuro e que parece importante se preparar para ele.
Não há problema algum em manter tudo rodando e destacar uma equipe para começar a trabalhar no plano de evolução, se realmente este for o caso. Já existe casos de sucesso suficiente para que possamos nos inspirar para lidar com situações como essa.
Jornada Dev + Eficiente
Se você está interessado em aprender mais sobre design de APIs, arquitetura de software e como evoluir suas soluções técnicas, recomendo que você explore mais sobre o Domain Driven Design e outras práticas que podem ajudar a guiar suas decisões de design. E, claro, se você quiser se aprofundar ainda mais, não deixe de conferir o treinamento da Jornada Dev + Eficiente (https://deveficiente.com/condicao-especial-30), onde você pode aprender comigo, Maurício Aniche, Rafael Ponte e toda nossa comunidade!
Até a próxima!
Top comments (0)