Dev sênior · Backend em Rust

Menos legado.
Mais solução.

Oi, eu sou o Luis Peterle, sócio e dev sênior na Simple Sistemas. Escrevo backend em Rust, já entreguei app em Flutter e convivo bem com Oracle. Mas o que eu faço de melhor é perguntar “por que X e não Y?” e deixar o sistema mais simples do que eu encontrei.

I use Arch BTW
role pra ver mais

Sócio e dev sênior na Simple Sistemas.

A Simple nasceu dentro do varejo, numa trajetória que começou em 1963, e hoje entrega um ecossistema completo de sistemas pra loja, do PDV ao ERP. Antes de ser software house, ela é varejo e operação de loja. Por isso cada sistema é feito por quem conhece o balcão.

“Transformamos operações complexas em sistemas simples, claros e escaláveis.”
missão da Simple, e a mesma ideia que guia o meu trabalho

stack da Simple:RustAstroFluttera mesma que eu uso.

produtos em que eu atuo
  • PDV SimplePonto de venda: vendas, estoque, emissão fiscal e múltiplos pagamentos.
  • ERP SimpleERP padronizado sobre o Senior, um dos maiores ERPs do Brasil.
  • Crédito & CRMAnálise de crédito, cobrança e renegociação de débitos.
  • E-commerce SimpleVenda online integrada ao ERP e ao PDV.
Conhecer a Simple 

Sistemas que rodam sem ninguém lembrar que eles existem.

Dois sistemas que eu construí no ecossistema da Simple: o problema, a solução e o resultado.

Reintegrador com o banco de dados

“Integração faseada”

problema
Lojas com internet instável, banco que às vezes cai, usuário reenviando a mesma requisição várias vezes e até tentativas de fraudar informação. E nenhum dado podia se perder.
solução
Cada integração é dividida em etapas, e cada etapa é marcada como concluída em arquivos no próprio sistema operacional. Se o banco cai, nada se perde: quando tudo volta, o integrador continua exatamente de onde parou. E a TI ainda consegue corrigir manualmente um campo da integração, como um cadastro incorreto, sem mexer em código.

0dados perdidos em 1 ano rodando em produção

  • funciona com banco offline
  • à prova de requisição duplicada
  • checkpoint por etapa
  • editável pela TI
Middleware de segurança da API

Controle de acesso

problema
Usuários internos e externos usando a mesma API, cada um com um nível de acesso, e tudo precisando ser seguro sem pesar no servidor.
solução
Uma camada única na frente da API que confere quem é o usuário, o que ele pode fazer e de onde ele está vindo, antes de qualquer coisa chegar ao sistema. Tudo de forma extremamente leve.
  • usuários internos e externos
  • permissionamento
  • criptografia ponta a ponta
  • logs
  • anti-DDoS
  • whitelist de IPs
2–3%

de uso do processador. Tudo isso roda num servidor bem modesto. Eficiência não é detalhe, é parte do projeto.

De HTML abandonado a backend em Rust.

Não foi uma linha reta. Testei, larguei o que não era pra mim e fui fundo no que fazia sentido.

  1. Infância

    Sempre fui do tech

    Desde criança, curioso por tudo que tinha tela, cabo ou botão.

  2. 2020 · Pandemia

    HTML & CSS

    Primeiro contato com código de verdade. Aprendi, percebi que não era minha praia e larguei, sem drama.

  3. 2021

    C

    Aqui clicou. Memória, ponteiro, o que a máquina realmente faz. Achei legal de verdade.

  4. 2022

    Kotlin

    Queria ser dev Android, então fui estudar Kotlin.

  5. 2023 · Lojas Adelino

    Estágio + Flutter do zero

    Entrei como estagiário e precisei aprender Flutter do absoluto zero, numa época em que IA ainda mal funcionava.

  6. 2026 · Hoje

    Sócio e dev sênior na Simple Sistemas

    Foco em backend com Rust, bagagem em Flutter, Oracle e Linux, construindo o ecossistema de sistemas da Simple pro varejo. E um olhar cada vez mais voltado pra solução, não pro código.

A IA ficou boa em codar. Eu fiquei melhor em resolver.

Felizmente, ou infelizmente, com o avanço da IA aquilo que eu achava que fazia de melhor, escrever código, ficou cada vez menos raro. Foi aí que descobri no que eu realmente sou bom: achar soluções inteligentes, sem ficar preso a legado, a tecnologias datadas, ao passado.

$ why --x --not-y

Por que X e não Y?

Toda escolha técnica precisa se justificar hoje, não “porque sempre foi assim”. Eu questiono, comparo e só então decido.

$ rm -rf legado/

Sem apego ao passado

Tecnologia datada não é argumento. Se uma integração não se paga mais, ela sai e entra algo mais inteligente no lugar.

$ make it --simple

Feito pra quem usa

O melhor sistema é o que o usuário comum opera sem manual. Complexidade fica no backend, não na tela.

Os bancos das empresas onde eu trabalho nunca estiveram tão lisos.

De tanta integração que removemos e trocamos por coisas mais inteligentes. A busca é constante: eficiência onde ela faz diferença e sistemas que o usuário comum consegue operar sem esforço.* mérito de toda a equipe.

Ferramentas que eu uso (e sei por que uso).

  • RustBackend — meu foco
  • FlutterMobile & multiplataforma
  • OracleBanco de dados
  • LinuxArch, claro
  • AstroWeb — este site, inclusive

Tem um sistema que precisa ficar mais simples?

Mais rápido, menos amarrado ao passado, mais fácil de operar. Se é esse o problema, vamos conversar.