Resumo Executivo

Augusto Magalhães Costa Neto; Ariel da Silva Dias

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

O comércio eletrônico consolidou-se como um dos setores mais relevantes da economia mundial, impulsionado pela digitalização e mudanças profundas nos hábitos de consumo. Segundo Turban et al. (2018), o setor de vendas digitais tem experimentado um crescimento acelerado devido ao avanço das tecnologias que facilitam o acesso a bens e serviços de forma remota. Laudon e Traver (2021) apontam que a mudança no comportamento dos consumidores, impulsionada pelo uso crescente de dispositivos móveis e pelo desenvolvimento de plataformas digitais, tem sido um dos principais fatores para a expansão do setor. Relatórios da UNCTAD (2024) destacam que o comércio eletrônico é responsável por uma parcela crescente do Produto Interno Bruto global, especialmente nos países em desenvolvimento, onde a penetração da internet está aumentando significativamente. No Brasil, a Associação Brasileira de Comércio Eletrônico registrou um faturamento superior a R$ 185 bilhões em 2023, e superior a R$ 204 bilhões em 2024, evidenciando a importância estratégica desse setor para o país (ABComm, 2025). Com o crescimento acelerado das transações online, torna-se essencial desenvolver soluções tecnológicas escaláveis e eficientes, capazes de acompanhar a evolução do mercado sem comprometer a experiência do usuário. Segundo Bondi (2000), a escalabilidade é um fator determinante para a qualidade de um sistema, permitindo que ele lide com uma quantidade crescente de trabalho de forma eficiente. Estudos da AWS (2025) e McKinsey (2024) apontam que uma arquitetura escalável é crucial para suportar picos de tráfego e garantir a disponibilidade dos serviços, especialmente em períodos de alta demanda, como a Black Friday. Paralelamente, a segurança cibernética desempenha um papel fundamental na proteção das informações dos consumidores e na prevenção de fraudes. De acordo com a OWASP (2025), vulnerabilidades em interfaces de programação de aplicações podem levar a exposição de dados sensíveis e ataques maliciosos, o que torna essencial a implementação de boas práticas de segurança. Outro fator crítico para o sucesso das plataformas de comércio eletrônico é a experiência do usuário. Segundo o Baymard Institute (2025), cerca de 70% dos carrinhos de compra são abandonados devido a problemas na usabilidade, enquanto estudos do Nielsen Norman Group (2010) indicam que sites com desempenho insatisfatório apresentam altas taxas de rejeição, impactando diretamente as vendas. Diante desse cenário, o desenvolvimento de uma infraestrutura robusta, capaz de suportar o crescimento dos negócios online, inclusive em momentos de alto tráfego suscitado por campanhas de marketing, torna-se o objetivo central para garantir a viabilidade técnica e comercial de sistemas modernos.

A metodologia adotada baseou-se em um estudo de caso com a implementação de uma interface de programação de aplicações do tipo transferência de estado representacional, atingindo o nível 2 de maturidade de Richardson. Para a construção do sistema, utilizou-se o framework Django Ninja, integrando princípios de arquitetura escalável, boas práticas de segurança e testes automatizados. A arquitetura aplicada foi inspirada na Clean Architecture (Martin, 2017) e nos princípios do Domain-Driven Design (Evans, 2003). O código foi organizado para separar claramente o núcleo de domínio das dependências de infraestrutura e da camada de apresentação. Na prática, isso se traduziu na criação de módulos específicos para entidades e objetos de valor, representando o domínio puro; repositórios e adaptadores de persistência, utilizando interfaces e implementações concretas via mapeamento objeto-relacional do Django; serviços de aplicação que orquestram casos de uso; e a camada de interface propriamente dita. Essa separação permite que as regras de negócio permaneçam testáveis e independentes de frameworks, facilitando a manutenção e possíveis migrações tecnológicas futuras. A divisão física do repositório espelhou essa intenção, com cada aplicação contendo arquivos específicos para entidades, repositórios, serviços e interfaces, refletindo a responsabilidade de cada camada. A modelagem do domínio procurou mapear os conceitos centrais do comércio eletrônico de forma explícita, atribuindo a cada entidade responsabilidades bem definidas e invariantes que devem ser preservadas ao longo de todas as operações. A entidade de usuário foi modelada como uma raiz de agregado, implicando que a consistência transacional de suas operações deve ser garantida pelo próprio agregado. O identificador do usuário foi definido como um identificador único universal, garantindo unicidade global e reduzindo a exposição de padrões previsíveis de identificação. Atributos como nome e nome de usuário foram representados por objetos de valor, responsáveis por validar automaticamente o tamanho máximo, os caracteres permitidos e a unicidade lógica. O campo de correio eletrônico passou por validação de formato e normalização antes de ser persistido. A segurança das credenciais foi tratada com rigor: a senha nunca é armazenada em texto puro, sendo imediatamente derivado um hash seguro por meio do algoritmo PBKDF2 com função de hash SHA-256, conforme recomendações da OWASP (2025).

A entidade de endereço relaciona-se com o usuário em uma proporção de um para muitos. Cada endereço foi modelado com objetos de valor para campos sensíveis como código de endereçamento postal, rua, número, cidade, estado e país, encapsulando regras de formatação e validação. Como cada país possui regras próprias para códigos postais, adotou-se o padrão de projeto Strategy para gerar contratos de implementação de verificação de acordo com o país de origem. Uma fábrica de objetos retorna a implementação correta baseada no código da localidade informado no payload. Por exemplo, a estratégia para o Brasil utiliza a interface da BrasilAPI como fonte de consulta, enquanto a estratégia para os Estados Unidos comunica-se com o serviço Zippopotam. No que tange aos produtos e categorias, a entidade de produto armazena informações como título, descrição, preço, estoque e status de atividade. O campo de preço é um objeto de valor que garante precisão no tratamento de valores monetários utilizando decimais com escala fixa, evitando erros de arredondamento comuns em tipos de ponto flutuante. O estoque também é encapsulado por um objeto de valor que valida limites aceitáveis e oferece métodos explícitos para débitos e reposição, evitando manipulações diretas. A relação entre produto e categoria foi modelada como muitos para muitos, permitindo flexibilidade organizacional. Na camada de interface, a representação do produto retorna categorias aninhadas, melhorando a usabilidade e reduzindo a necessidade de múltiplas requisições, o que contribui para a redução de custos operacionais em ambientes de computação em nuvem (AWS, 2025). O gerenciamento de pedidos foi estruturado através da entidade de pedido, que agrega múltiplos itens de pedido. Cada item preserva uma cópia do preço do produto no momento da compra para manter o histórico imutável. O cálculo dos totais é realizado no domínio, sem confiar em entradas do usuário para valores monetários. Os status de pedido foram explicitados por uma máquina de estados simples, utilizando uma enumeração que define estados como criado, pago, enviado, concluído e cancelado. A transição entre estados é validada para evitar passos inválidos, como o envio de um pedido sem pagamento aprovado.

Para garantir a integridade dos dados sob condições de alta concorrência, as operações que envolvem recursos compartilhados, como a atualização de estoque, foram projetadas com travas pessimistas. Utilizou-se o mecanismo de seleção para atualização do mapeamento objeto-relacional do Django, garantindo que apenas uma operação seja aplicada por vez sobre o mesmo registro. Todo o fluxo de criação de pedidos é encapsulado em um contexto transacional atômico. Se ocorrer uma falha em qualquer ponto, um rollback automático desfaz as alterações intermediárias, respeitando os princípios de atomicidade, consistência, isolamento e durabilidade dos bancos de dados relacionais. A segurança e conformidade com a Lei Geral de Proteção de Dados foram tratadas em múltiplas camadas. Além do hashing de senhas, a transmissão de dados sensíveis utiliza canais seguros baseados em segurança de camada de transporte. A autenticação foi implementada utilizando tokens de rede JSON, um padrão aberto definido pela RFC 7519 (Jones, Bradley e Sakimura, 2015). Esses tokens são assinados digitalmente e configurados com tempo de vida reduzido, utilizando estratégias de tokens de atualização para mitigar riscos de sequestro de sessão. O princípio da minimização de dados foi aplicado, registrando apenas informações estritamente necessárias e utilizando técnicas de anonimização para reduzir riscos de exposição indevida. Os logs do sistema foram configurados para evitar a gravação de informações pessoalmente identificáveis, equilibrando segurança e observabilidade. A autorização é aplicada por meio de decoradores que simplificam verificações de acesso, impedindo que usuários inativos acessem endpoints críticos. A estratégia de testes combinou testes unitários agrupados no nível de serviço, testes de integração para validar fluxos ponta a ponta e testes de concorrência multithread. Para medir o desempenho, desenvolveu-se um utilitário interno denominado TimedClient, capaz de registrar durações em milissegundos. A observabilidade foi reforçada por um módulo central de registro estruturado com correlação por requisição, facilitando o monitoramento e a identificação de problemas críticos em ambientes de containers, seguindo os princípios da aplicação de 12 fatores (Wiggins, 2011). O sistema foi projetado para integração com o Prometheus para exposição de métricas de latência e vazão, com visualização em painéis do Grafana.

Os resultados e a discussão subsequente baseiam-se em testes executados em ambiente Docker orquestrado, utilizando imagens oficiais de banco de dados PostgreSQL 15, Prometheus, Grafana e Locust. O hardware de referência consistiu em um processador Intel Core i5-8265U com 8 GB de memória RAM. Embora modesto em comparação com ambientes de nuvem, esse hardware permitiu interpretar tendências de escalabilidade e comportamento relativo. Adotou-se como referência prática de experiência do usuário o patamar de 800 ms para latência, valor 20% abaixo do limite de 1000 ms recomendado na literatura clássica para manter o fluxo de pensamento do usuário sem ruptura (Nielsen Norman Group, 2010). Três cenários de carga foram desenhados para validar hipóteses de funcionalidade, consistência e escalabilidade. No cenário focado em rajadas de leitura, o driver de carga concentrou-se em requisições do tipo GET para listagem de produtos por categoria e consulta de detalhes de produtos específicos. Esse arranjo isolou a capacidade de consulta do sistema. Em uma primeira rodada com pico de 10 usuários e taxa de propagação de um usuário por segundo, registraram-se 1747 requisições totais com zero falhas. A mediana de latência foi de 27 ms, enquanto o percentil 95 atingiu 41 ms e o percentil 99 chegou a 61 ms. A vazão média foi de 6,8 requisições por segundo. Em uma segunda rodada, dobrando o pico para 20 usuários e a taxa de propagação para dois usuários por segundo, o volume total subiu para 3490 requisições, mantendo zero falhas. A mediana de latência subiu levemente para 33 ms, com o percentil 95 em 68 ms e o percentil 99 em 100 ms. A vazão média saltou para 15,2 requisições por segundo. Esses dados demonstraram um crescimento linear de vazão sem degradação significativa das latências centrais, confirmando que o caminho de leitura, beneficiado por uma serialização enxuta e consultas filtradas, é altamente escalável.

O segundo cenário avaliou a concorrência de escrita em um mesmo produto, simulando uma situação de esgotamento de estoque. Com 20 usuários e um estoque inicial de 800 unidades, o sistema processou 8519 requisições, das quais 1752 resultaram em falhas controladas, representando aproximadamente 21% do total. A vazão média foi de 33,5 requisições por segundo. As falhas começaram a surgir exatamente 135 s após o início do teste, coincidindo com o momento em que o estoque atingiu o valor zero. Todas as falhas foram identificadas com o código de status HTTP 409, indicando conflito, o que é o comportamento esperado quando a regra de negócio impede a venda de itens indisponíveis. A latência no percentil 95 foi de 297 ms. A análise dos logs e das métricas do Grafana confirmou que o sistema não permitiu vendas acima do disponível, preservando a integridade do banco de dados. Esse resultado valida a eficácia do uso de transações atômicas e travas pessimistas, garantindo que, sob disputa intensa, os registros sejam bloqueados corretamente e as tentativas excedentes sejam rejeitadas sem efeitos colaterais residuais. Do ponto de vista de consistência, o cenário confirmou a propriedade de atomicidade defendida na modelagem: as transações de criação de pedido ou completam com o débito do estoque e registro do pedido, ou abortam com erro adequado, conforme exigido pelos princípios ACID em operações críticas (Evans, 2003).

O terceiro cenário reproduziu o fluxo completo de um cliente, incluindo criação de usuário, autenticação, listagem por categoria, seleção de produto, inclusão no carrinho e criação do pedido. Diferente do cenário de esgotamento, aqui não houve disputa intensa sobre o mesmo recurso, mas sim múltiplos passos de escrita. O volume total foi de 3483 requisições com uma taxa de erro de 7,69%, concentrada especificamente no final do teste quando o estoque de diversos produtos começou a se esgotar. A vazão média foi de 10,7 requisições por segundo. Um ponto relevante observado foi a latência nas rotas de usuário. A criação de um novo usuário apresentou um tempo médio de 0,67 s, enquanto a alteração de senha registrou uma média de 1,90 s. Esses valores, embora acima da média das outras rotas, são justificados pelo custo computacional deliberado do algoritmo PBKDF2. O uso de múltiplos rounds de hashing é uma medida de segurança necessária para mitigar ataques de força bruta, e a latência observada está dentro dos limites aceitáveis para operações de cadastro e segurança que não ocorrem com alta frequência por usuário. A comparação entre os cenários evidenciou perfis distintos de custo: enquanto as leituras escalam com facilidade, as escritas são naturalmente mais onerosas devido às validações encadeadas, operações criptográficas e coordenação transacional. Esse diagnóstico orienta a evolução do sistema para uma separação mais clara entre os caminhos de leitura e escrita, possivelmente utilizando réplicas de leitura para aliviar o banco de dados principal.

A discussão integradora dos resultados aponta que a aderência à Clean Architecture e ao Domain-Driven Design favoreceu a testabilidade e a evolução independente do sistema. As invariantes de negócio permaneceram estáveis e centralizadas no domínio, enquanto a infraestrutura pôde ser ajustada para lidar com a carga. O controle explícito de concorrência provou ser eficaz, pois o sistema não degradou a consistência mesmo sob alta taxa de requisição. A estratégia de testes pragmática, focada em jornadas reais de negócio, permitiu identificar gargalos de desempenho e validar a correção lógica de forma eficiente. Para a evolução da interface de programação de aplicações, recomenda-se a consolidação da observabilidade através da integração de ferramentas de rastreamento de exceções ponta a ponta, como o Sentry, o que permitiria diagnósticos mais rápidos em caso de falhas pontuais. Além disso, a configuração de alertas operacionais baseados em limiares de latência e taxas de erro é fundamental para uma operação proativa. Outra recomendação importante é o isolamento dos caminhos de leitura e escrita. Como as leituras apresentaram excelente escalabilidade, a separação física desses caminhos, utilizando pools dedicados ou réplicas, reduziria a contenção de recursos no banco de dados. O processamento assíncrono também deve ser explorado para etapas computacionalmente custosas que não exigem resposta imediata ao usuário, como a emissão de eventos de auditoria ou o recálculo de agregados estatísticos. Essa estratégia reduziria a latência das rotas síncronas e preservaria a integridade do núcleo transacional. A adoção de microsserviços pode ser considerada no futuro, mas apenas quando o ganho marginal de escala justificar o aumento da complexidade de infraestrutura. No estágio atual, a arquitetura monolítica modularizada mostrou-se suficiente para atender às metas de desempenho e segurança estabelecidas.

Conclui-se que o objetivo foi atingido por meio da concepção e validação de uma interface de programação de aplicações para comércio eletrônico orientada por princípios de arquitetura limpa e invariantes de domínio explícitas, resultando em um sistema consistente, observável e capaz de manter a integridade dos dados sob alta concorrência. Os experimentos demonstraram que a combinação de transações atômicas com mecanismos de trava pessimista impediu falhas críticas como a venda de produtos sem estoque, enquanto a estrutura baseada em objetos de valor garantiu a precisão dos cálculos monetários e a segurança das credenciais dos usuários. A análise de desempenho revelou uma distinção clara entre a alta eficiência das operações de leitura e o custo computacional necessário das operações de escrita e segurança, fornecendo um roteiro claro para futuras otimizações, como a implementação de processamento assíncrono e o isolamento de caminhos de dados. O trabalho entrega, assim, um artefato técnico robusto e um método de avaliação replicável, aptos a suportar o crescimento de plataformas de comércio eletrônico com rigor conceitual e viabilidade prática.

Referências Bibliográficas:

Amazon Web Services [AWS]. 2025. Amazon API Gateway – Pricing. Disponível em: <https://aws.amazon.com/pt/api-gateway/pricing/>. Acesso em: 22 set. 2025.

Associação Brasileira de Comércio Eletrônico [ABComm]. 2025. Dados do e-commerce brasileiro. Disponível em: <https://dados.abcomm.org/>. Acesso em: 22 set. 2025.

Baymard Institute. 2025. Reasons for Cart Abandonment – Why 70% of Users Abandon Their Cart. Disponível em: <https://baymard.com/blog/ecommerce-checkout-usability-report-and-benchmark>. Acesso em: 22 set. 2025.

Bondi, A.B. 2000. Characteristics of Scalability and Their Impact on Performance. In: International Workshop on Software and Performance (WOSP 2000), 2000, Ottawa, ON, Canadá. Anais… p. 195-203.

Evans, E. 2003. Domain-Driven Design: Tackling Complexity in the Heart of Software. 1ed. Addison-Wesley, Boston, MA, EUA.

Jones, M.B.; Bradley, J.; Sakimura, N. 2015. JSON Web Token (JWT). RFC 7519. Disponível em: <https://www.rfc-editor.org/rfc/rfc7519>. Acesso em: 22 set. 2025.

Laudon, K.C.; Traver, C.G. 2021. E-commerce 2021: Business, Technology, Society. 16ed. Pearson, Boston, MA, EUA.

Martin, R.C. 2017. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. 1ed. Pearson, Boston, MA, EUA.

McKinsey & Company. 2024. Power forward: Five make-or-break truths about next-gen e-commerce. Disponível em: <https://www.mckinsey.com.br/our-insights/power-forward-five-make-or-break-truths-about-next-gen-e-commerce>. Acesso em: 22 set. 2025.

Nielsen Norman Group [NN/g]. 2010. Website Response Times. Disponível em: <https://www.nngroup.com/articles/website-response-times/>. Acesso em: 22 set. 2025.

Open Web Application Security Project [OWASP]. 2025. Password Storage Cheat Sheet. Disponível em: <https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html>. Acesso em: 22 set. 2025.

Turban, E.; Outland, J.; King, D.; Lee, J.K.; Liang, T-P.; Turban, D.C. 2018. Electronic Commerce 2018: A Managerial and Social Networks Perspective. 9ed. Springer International Publishing, Cham, Suíça.

United Nations Conference on Trade and Development [UNCTAD]. 2024. E-Commerce and Digital Economy Programme: Year in Review 2023 (Summary). Disponível em: <https://unctad.org/publication/e-commerce-and-digital-economy-programme-year-review-2023>. Acesso em: 22 set. 2025.

Wiggins, A. 2011. The Twelve-Factor App. Disponível em: <https://12factor.net/>. Acesso em: 22 set. 2025.

Resumo executivo oriundo de Trabalho de Conclusão de Curso de Especialização em Engenharia de Software do MBA USP/Esalq

_{Saiba mais sobre o curso; clique aqui:}