PYTHON

ELEGANTE. FLEXÍVEL. PODEROSO.

QUAL SERÁ O ANIMAL
TOTEM DO
SEU BACKEND?

Construímos sistemas backend robustos, seguros, escaláveis e projetados para alta performance.

RUST

SEGURO. RÁPIDO. CONCORRENTE.

01 Duas linguagens. Não cinco.

Uma pilha, escolhida a propósito.

Agências poliglotas soam bem numa apresentação de vendas. Na prática, significam três sistemas de compilação, quatro variações de null e um cemitério de serviços mal mantidos. Escolhemos duas linguagens que cobrem 95% das cargas de trabalho reais — e tornámo-nos muito, muito bons em ambas.

Caminho crítico · sistemas · segurança

Rust

9,6 índice de ajuste interno

Seguro em termos de memória sem um coletor de lixo. Livre de conflitos de dados em tempo de compilação. O revisor de código mais exigente que alguma vez terá — e, assim que o aprovar, o seu serviço não o acordará ao domingo.

Quando o procuramos

  • Canais de pagamento e tudo o que envolva dinheiro ou dados pessoais identificáveis
  • Gateways de API de alta disponibilidade com SLAs de 99,999%
  • Mecanismos de correspondência de baixa latência, negociação, em tempo real
  • Módulos WebAssembly enviados para o navegador
  • Ferramentas CLI e daemons que devem iniciar em milésimos de segundo

Compromissos que não ignoramos

  • Integração de novos colaboradores: ~2–4 semanas até à produtividade
  • Tempos de compilação em espaços de trabalho enormes (resolvemos com sccache)
  • Ecossistema mais recente do que o Java — maduro onde é importante
Glue · dados · ML · velocidade

Python

9,3 índice de ajuste interno

O caminho mais rápido do quadro branco ao sistema funcional. O ecossistema mais rico do mundo para dados, ML e automação. Python moderno — 3.12, uv, ruff, pydantic, FastAPI — é uma linguagem precisa, tipada e suficientemente rápida para a maior parte do que precisa.

Quando o procuramos

  • Ferramentas internas, painéis de controlo e painéis de administração
  • ETL, pipelines de dados, Airflow / Dagster / Prefect
  • ML — treino, implementação, avaliação
  • Automatizações e integrações com APIs de fornecedores
  • MVPs lançados neste trimestre, não no próximo ano

Compromissos que não ignoramos

  • O rendimento de um único núcleo é 20–50 vezes mais lento do que o Rust
  • Maior consumo de memória por solicitação — fatal para algumas cargas de trabalho
  • A tipagem dinâmica apresenta problemas sem o uso rigoroso do mypy / pydantic
Rust, onde o erro custa caro. Python, onde o atraso no lançamento é caro. Uma equipa. Zero dogmas.
02 De → Para

O que muda quando você migra.

Escolha uma linguagem de partida. Veja o impacto de migrar para Rust ou Python. Os números são medianas dos nossos últimos 40 projetos de migração, não papo de marketing.

Rust vs Python vs C / C++

Resultados de engenharia do mundo real comparados ao stack de origem selecionado.

Rust Python C / C++ baseline

Sinais no nível do stack

Fatores qualitativos de engenharia que importam além dos números de desempenho.

A linha tracejada cinza mostra o stack de origem selecionado. Rust e Python são medidos em relação a essa linha de base, não um contra o outro.

Como medimos esses números

Medianas de 40 migrações concluídas entre 2023 e 2026. O throughput é medido na camada de aplicação (p50 de ponta a ponta sob carga realista, não microbenchmarks). A memória é RSS em estado estável. O custo é computação mensal sob demanda na AWS/GCP, tudo o mais igual. Os resultados individuais variam — também publicamos os que não saíram conforme o planejado, mediante solicitação.

03 Números sem asteriscos

Requisições por segundo sob carga real.

Carga de trabalho idêntica — validar JSON → consultar Postgres → renderizar — medida em uma única máquina AMD Ryzen 7. Estes não são microbenchmarks. Fonte & metodologia ↓

  1. 1 Rust · Axum
    21,030 req/s
  2. 2 C# .NET · ASP.NET Core
    14,707 req/s
  3. 3 Node.js · Fastify
    9,340 req/s
  4. 4 C++ · Drogon
    7,200 req/s
  5. 5 Go · Gin
    3,546 req/s
  6. 6 Python · FastAPI (Uvicorn)
    1,185 req/s
  7. 7 PHP · Laravel
    299 req/s

Leia isso corretamente: Python está perto do fundo deste gráfico, e tudo bem. Não usamos FastAPI no caminho crítico. Usamos onde 1.185 req/s já é ~10× mais do que a carga precisa, e horas de engenheiro valem mais do que ciclos de CPU. Metodologia: AMD Ryzen 7, Linux, Docker, instância única, um framework popular por linguagem. Os números são médias de múltiplas execuções.

05 O custo real de código defeituoso

O que uma interrupção realmente lhe custa.

«Cinco noves» não é marketing. Abaixo está o que custa uma hora de inatividade não planeada, por setor — com fontes. Construímos o Rust onde estes números existem.

Custo acumulado desde que abriu esta secção
Finanças / saúde $0 ~83 mil dólares/min · 5 milhões de dólares/hora
Automóvel $0 ~38 mil $/min · 2,3 milhões $/h
Grandes empresas 0 23 750 $/min · 1,4 milhões de $/h
Empresa de média dimensão 0 ~5 mil $/min · 300 mil $/h
Finanças e cuidados de saúde Mais de 5 milhões de dólares por hora

Os setores de maior risco. As plataformas de negociação, os sistemas de liquidação e os sistemas clínicos podem ultrapassar os 5 milhões de dólares por hora durante uma interrupção grave — antes de se contabilizarem quaisquer custos regulamentares ou de litígio.

Fonte: Estudo da Gartner sobre a Fortune 500 de 2024; Custo por hora do tempo de inatividade da ITIC de 2024.
Fabrico automóvel 2,3 milhões de dólares / hora

Uma linha de produção paralisada representa um prejuízo de cerca de 640 dólares por segundo. A interrupção dos serviços da CrowdStrike em julho de 2024 custou à Delta Air Lines, só a ela, 380 milhões de dólares em cinco dias.

Fonte: Análise setorial do Erwood Group de 2025; análise pós-incidente da Antithesis sobre a CrowdStrike.
Grande empresa (média) 1,4 milhões de dólares/hora

Número da BigPanda para grandes empresas em 2024: 23 750 dólares por minuto. O ITIC relata que 41% das grandes empresas perdem entre 1 milhão e 5 milhões de dólares por hora de interrupção.

Fonte: Investigação da BigPanda para 2024; 11.º Relatório Anual do ITIC sobre o Custo Horário do Tempo de Inatividade.
Global 2000 (Oxford Economics) 400 mil milhões de dólares / ano

Custo total oculto do tempo de inatividade não planeado nas 2.000 maiores empresas do mundo, segundo o estudo de 2024 da Oxford Economics — com um impacto médio de 200 milhões de dólares por empresa quando se somam receitas, produtividade e reparação.

Fonte: Oxford Economics 2024, “The Hidden Costs of Downtime”.
Médias e grandes empresas (hora típica) Mais de 300 mil dólares / hora

Inquérito da ITIC de 2024: mais de 90% das médias e grandes empresas consideram agora que uma única hora de tempo de inatividade não planeado ultrapassa este limite — excluindo penalizações legais, civis ou regulamentares.

Fonte: Relatório do ITIC de 2024 sobre o custo por hora do tempo de inatividade.
Pequenas e médias empresas (PME) 25 000–150 000 $ / hora

O estudo conjunto ITIC/Calyptix de 2025 revela que muitas PME perdem este valor por hora; a Siemens relata que as PME afetadas por interrupções podem chegar a perder até 150 000 dólares por hora. A duração média de uma interrupção é de 87 minutos.

Fonte: ITIC + Calyptix 2025; Siemens True Cost of Downtime 2024.
06 Trabalhos selecionados

Três projetos. Três desafios diferentes.

Anonimizados onde o acordo de confidencialidade o exige, específicos onde os resultados o justificam. Estes são os projetos que apresentaríamos em primeiro lugar a um comprador técnico.

  1. Caso 01 Python Base de dados Criptografia RGPD

    Cofre de dados Fintech: 4 vezes menor, 5,5 vezes mais rápido, em conformidade global.

    O cliente mantinha um cluster Postgres de 1,8 TB sobrecarregado com colunas legadas, índices inativos e BLOBs com encriptação inline que tinham crescido ao longo de sete anos. A criptografia era executada numa biblioteca obsoleta sinalizada em três auditorias distintas. O risco regulatório era real; os auditores estavam de olho.

    O que fizemos

    • Auditoria completa do esquema e da utilização, remoção de colunas e índices não utilizados, introdução de particionamento adequado.
    • Migrar o pipeline de criptografia de uma biblioteca legada para uma pilha AEAD moderna e auditada com chaves rotativas.
    • Converter a encriptação BLOB-inline para encriptação de envelope referenciada + KMS dedicado.
    • Alinhar a retenção de dados e os fluxos de acesso dos titulares de dados com o RGPD, a CCPA e a APPI.
    Resultado

    Os mesmos dados, um quarto da conta de armazenamento, 5,5 vezes mais rendimento e um atestado de boa saúde para o próximo regulador que viesse bater à porta.

  2. Caso 02 Rust C++ → Rust Segurança Armazenamento

    Serviço em C++ reescrito em Rust: mais de 100 bugs da classe CVE eliminados em 9 semanas.

    Serviço de processamento de ficheiros voltado para o utilizador em C++, que falhava a cada 4–5 dias e era corrigido no local de cada vez. A nossa auditoria revelou mais de 100 bugs reais: caminhos de negação de serviço, transbordamentos de buffer, tratamento de pedidos sem limites. Os erros 503 nas horas de pico eram um ritual semanal. No lado do armazenamento, os uploads dos utilizadores tinham-se acumulado numa confusão de ficheiros duplicados que esgotavam o espaço de armazenamento.

    O que fizemos

    • Reescrita completa em Rust (axum + tokio) com validação rigorosa de entradas e limites de recursos definidos.
    • Testes baseados em propriedades + cargo-fuzz em todos os analisadores e limites de formato de transmissão.
    • Camada de armazenamento endereçada por conteúdo com desduplicação no momento da gravação.
    • Implementação blue-green num intervalo de integração de 4 horas, sem tempo de inatividade.
    Resultado

    O serviço passou de «frágil e remendado semanalmente» para «deixámos de olhar para o pager». Os custos de armazenamento baixaram com a deduplicação, os tickets de suporte sobre erros e 503s desapareceram, e a reescrita pagou-se a si própria no espaço de um trimestre.

  3. Caso 03 Rust Python eBPF / XDP CRM · 4 mil utilizadores

    CRM empresarial, reconstruído: 18 servidores → 5, redução de custos de mais de 60%.

    CRM interno a servir mais de 4.000 utilizadores em IAM, SOC, registo centralizado, chat, partilha de ficheiros, VoIP e dados encriptados de ponta a ponta. Dezoito servidores, Cloudflare por cima, e uma fatura de nuvem que continuava a crescer independentemente do número de colaboradores. Reconstruímos o caminho ativo em Rust, mantivemos o Python na camada de integração e relatórios e colocámos um filtro eBPF/XDP diretamente à frente da entrada.

    O que fizemos

    • Serviços Rust para autenticação (IAM), mensagens em tempo real, sinalização VoIP e transferência de ficheiros.
    • Python para interfaces de administração, relatórios, correlação de eventos SOC e integração com APIs de fornecedores.
    • Filtragem de bots e abusos via eBPF/XDP no kernel — substituiu o Cloudflare para esta carga de trabalho.
    • Pipeline de registo estruturado reescrito em torno de um esquema de cópia zero.
    Resultado

    Treze servidores a menos, fim da rubrica orçamental da Cloudflare, a equipa do SOC vê um sinal mais claro através do pipeline de registo, e o diretor financeiro deixou de fazer perguntas incómodas sobre o orçamento de infraestrutura.

07 Como trabalhamos na prática

Ajuste os parâmetros. Veja o plano a mudar.

Cada projeto equilibra velocidade, custo e fiabilidade. A estimativa em cinco fases abaixo é calibrada em relação às medianas do setor (descoberta 2–6 semanas, arquitetura 1–4 semanas, implementação 4–20 semanas, reforço 2–8 semanas, entrega 1–2 semanas — de acordo com relatórios de 2024–2026 da NIX United, Agilie, SOLTECH, OTG Lab). Mova os controles deslizantes; o plano é recalculado em tempo real.

01

Descoberta

3 semanas

Leia o seu código, entreviste a sua equipa de operações, liste as incógnitas, escolha a linguagem por componente.

  • Entrevistas sobre o domínio e auditoria de código
  • Registo de riscos e metas do SLA
  • Decisão sobre a linguagem por serviço
02

Arquitetura

2 semanas

Contratos antes do código. OpenAPI / protobuf, modelos de dados, topologia de implementação, esboços de manuais de operações.

  • RFCs para todos os contratos públicos
  • Modelo de dados + plano de migração
  • Linha de base de infraestrutura como código
03

Implementação

8 semanas

Pequenos PRs, CI aprovado desde o primeiro dia, implementações em cada fusão, revisão por um segundo sénior.

  • Rust: axum · tonic · sqlx
  • Python: FastAPI · Pydantic · SQLAlchemy
  • Demonstrações semanais + registo de alterações
04

Reforço

3 semanas

Fuzzing, testes baseados em propriedades, testes de carga com tráfego realista, modelo de ameaças.

  • cargo-fuzz · proptest · hypothesis
  • Testes de carga k6 vinculados a SLOs
  • Revisão de segurança e auditoria de dependências
05

Entrega

1 semana

Runbooks, rotação de plantão, ADRs e uma equipa que já lançou isto uma vez.

  • Manuais de procedimentos + matriz de plantões
  • Registo de ADR e diagramas de arquitetura
  • Suporte pós-lançamento de 30 dias
08 O mesmo problema, duas linguagens

Como o mesmo endpoint se apresenta em cada uma.

Recuperar um utilizador, validar a entrada, persistir no Postgres, devolver JSON. Alterne entre as linguagens — ambas são código real que realmente lançaríamos.

SQL_CREATE_USER = "insert into users(email,name) values(lower($1),$2) returning id,email,name"
Name = Annotated[str, StringConstraints(strip_whitespace=True, min_length=1, max_length=120)]

class UserIn(BaseModel):
    email: EmailStr
    name: Name

class UserOut(UserIn):
    id: int

@router.post("/users", response_model=UserOut, status_code=201)
async def create_user(u: UserIn) -> UserOut:
    try:
        row = await pool.fetchrow(SQL_CREATE_USER, str(u.email), u.name)
   except UniqueViolationError as exc:
        raise HTTPException(status_code=409, detail="email já existe") from exc
    if row is None:
        raise HTTPException(status_code=500, detail="falha na inserção")
    return UserOut.model_validate(dict(row))
#[derive(Deserialize, Validate)]
#[serde(deny_unknown_fields)]
pub struct UserIn {
    #[validate(email)]
    pub email: String,
    #[validate(custom(function = "valid_name"))]
    pub name: String,
}

pub async fn create_user(
    State(pool): State<PgPool>,
    ValidatedJson(u): ValidatedJson<UserIn>,
) -> Result<(StatusCode, Json<UserOut>), ApiError> {
   let user = sqlx::query_as!(UserOut,
        "insert into users(email,name) values(lower($1),$2) returning id,email,name",
        u.email.as_str(),
        u.name.trim(),
    )
    .fetch_one(&pool)
    .await
    .map_err(ApiError::from_db)?;

    Ok((StatusCode::CREATED, Json(user)))
}
Linhas de código
16 22
Rendimento
1.185 req/s 21 030 req/s
Latência p50
21,0 ms 1,6 ms
RAM em modo inativo
41,2 MB 8,5 MB
Respondemos no prazo de 1 dia útil. Não estamos a brincar.

Você leu a página inteira.
Vamos construir isto.

Diga-nos o que está errado com a sua pilha de tecnologias, ou o que pretende construir do zero. Receberá uma opinião técnica genuína — não um argumento de vendas.

  • Sem engenheiros juniores. Sem subcontratação no estrangeiro.
  • Opções de preço fixo para trabalhos com âmbito definido.
  • NDA assinado antes de lhe fazermos qualquer pergunta.