Construindo um SaaS com IA: arquitetura, custos e stack completo

Rocketseat

5 min de leitura

Conheça o Rocketseat Para Empresas

Oferecemos soluções personalizadas para empresas de todos os portes.

Muita gente decide construir um SaaS com IA depois de ver um protótipo funcionando bem em poucas horas. O modelo responde rápido, o demo impressiona o time e a sensação é de que falta pouco para lançar. O problema aparece algumas semanas depois, quando a fatura da API de IA chega três vezes maior que o previsto, a latência começa a incomodar os primeiros usuários e ninguém sabe exatamente onde estão os gargalos.

Isso acontece porque um protótipo de IA e um produto de IA em produção são coisas diferentes. O protótipo só precisa provar que a ideia funciona. O produto precisa lidar com custo por usuário, cache, filas, limites de taxa dos provedores, versionamento de prompts e observabilidade, tudo isso sem perder a experiência que fez o protótipo parecer mágico.

A ideia aqui é você entender como pensar a arquitetura de um SaaS com IA desde o início, quais peças de stack fazem sentido em cada camada e onde normalmente moram os custos escondidos, para que a transição de MVP para produto em produção não vire uma surpresa desagradável.

Arquitetura de um SaaS com IA

Um SaaS com IA bem estruturado costuma ser dividido em três camadas que conversam entre si, mas que podem escalar de forma independente.

Camada de aplicação

É a parte visível para o usuário: frontend, autenticação, cobrança, painel administrativo. Tecnicamente não tem nada de especial em relação a um SaaS tradicional, mas é aqui que fica a responsabilidade de controlar o que o usuário pode fazer, quantas requisições ele já consumiu no plano e como o resultado da IA é exibido, incluindo streaming de resposta quando faz sentido.

Camada de IA

Concentra tudo que envolve chamar modelos de linguagem: orquestração de prompts, escolha de provedor, RAG (retrieval augmented generation) quando o produto depende de dados próprios, e as regras de fallback caso um provedor esteja indisponível ou lento. É comum separar essa camada em um serviço próprio, para que ela possa escalar e ser monitorada de forma isolada da aplicação principal.

Camada de dados

Guarda tanto os dados relacionais do produto (usuários, planos, histórico) quanto os dados específicos de IA: embeddings para busca semântica, cache de respostas, logs de prompts e resultados para auditoria e para futuras iterações de fine-tuning, se o produto chegar nesse ponto.

Separar essas três camadas desde o início evita um erro comum, que é acoplar a lógica de negócio diretamente às chamadas de IA. Quando isso acontece, trocar de provedor de modelo ou ajustar um prompt vira uma tarefa arriscada, porque mexe em código que também cuida de cobrança e autenticação.

Stack completo: as escolhas que fazem sentido

Não existe uma stack única certa, mas existe um conjunto de decisões que se repete em produtos de IA que escalam bem.

Frontend

React ou Next.js continuam sendo as escolhas mais comuns, principalmente porque o suporte a streaming de resposta (mostrar o texto sendo gerado token por token) já é bem resolvido no ecossistema, o que melhora bastante a percepção de velocidade do produto.

Backend e API

Node.js com TypeScript ou Python com FastAPI são as opções mais usadas. FastAPI tende a ganhar quando a camada de IA está no mesmo time que cuida do backend, porque o ecossistema de IA em Python (bibliotecas de orquestração, SDKs de provedores, ferramentas de RAG) é mais maduro.

Orquestração de IA

Frameworks como LangChain ou LlamaIndex ajudam a organizar RAG e cadeias de prompts, mas vale a ressalva de que para produtos mais simples, chamar a API do provedor diretamente, sem framework, costuma ser mais fácil de debugar e de manter no médio prazo.

Banco de dados e cache

Postgres com a extensão pgvector resolve bem tanto os dados relacionais quanto os embeddings para a maioria dos SaaS, sem precisar de um banco vetorial separado logo no início. Redis entra como camada de cache, tanto para respostas de IA repetidas quanto para controle de limites de uso por usuário.

Custos: onde o dinheiro vai embora

O custo de um SaaS com IA não é só "preço por token". Ele se divide em pelo menos três frentes.

Custo por token vs custo por usuário

É fácil calcular o custo de uma chamada isolada, mas o que importa para o negócio é o custo por usuário ativo. Um usuário que faz várias perguntas parecidas ao longo do dia pode custar muito menos se o produto tiver cache semântico, porque nem toda pergunta precisa virar uma nova chamada ao modelo.

Cache semântico para reduzir custos

A ideia é simples: antes de chamar o modelo, verificar se uma pergunta muito parecida já foi respondida recentemente. Isso é feito comparando o embedding da nova pergunta com embeddings já armazenados.


# Exemplo simplificado de cache semântico usando Redis
# O objetivo é evitar chamar o modelo de IA para perguntas muito parecidas

import redis
import json
import numpy as np

cache = redis.Redis(host="localhost", port=6379, db=0)

def similaridade_cosseno(vetor_a: list[float], vetor_b: list[float]) -> float:
    """Calcula a similaridade entre dois embeddings."""
    a = np.array(vetor_a)
    b = np.array(vetor_b)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

def buscar_no_cache(embedding_pergunta: list[float], limite: float = 0.92) -> str | None:
    """Percorre as respostas em cache e retorna a mais parecida, se houver."""
    chaves = cache.keys("cache:pergunta:*")

    for chave in chaves:
        item = json.loads(cache.get(chave))
        score = similaridade_cosseno(embedding_pergunta, item["embedding"])

        if score >= limite:
            return item["resposta"]

    return None

def salvar_no_cache(pergunta: str, embedding: list[float], resposta: str):
    """Guarda a pergunta, o embedding e a resposta para reaproveitar depois."""
    chave = f"cache:pergunta:{hash(pergunta)}"
    valor = json.dumps({"embedding": embedding, "resposta": resposta})
    # expira em 24 horas, ajuste conforme o caso de uso do produto
    cache.setex(chave, 86400, valor)

Esse tipo de estratégia costuma reduzir de forma significativa o número de chamadas ao provedor de IA em produtos onde os usuários fazem perguntas repetitivas, como FAQs internas ou suporte ao cliente. Para detalhes sobre expiração de chaves e estruturas de dados, vale consultar a documentação oficial do Redis.

Infraestrutura e hospedagem

Além do custo de tokens, existe o custo de manter os servidores da aplicação, o banco de dados e, se houver, os workers que processam filas de tarefas assíncronas (como geração de relatórios longos ou processamento de documentos para RAG). Esses custos costumam ser mais previsíveis que os de IA, mas crescem junto com o número de usuários simultâneos.

Exemplo prático: endpoint de chat com streaming

Um exemplo de como estruturar um endpoint que recebe uma pergunta, verifica o cache e, se necessário, chama o modelo com streaming de resposta.


# Endpoint de exemplo usando FastAPI
# Recebe uma pergunta do usuário e retorna a resposta em streaming

from fastapi import FastAPI
from fastapi.responses import StreamingResponse
from pydantic import BaseModel

app = FastAPI()

class PerguntaRequest(BaseModel):
    pergunta: str
    usuario_id: str

async def gerar_resposta_streaming(pergunta: str):
    """Simula a geração de resposta em streaming, token por token."""
    # aqui entraria a chamada real ao provedor de IA,
    # usando o modo de streaming oferecido pela SDK dele
    resposta_simulada = "Aqui vai a resposta gerada pelo modelo de IA."

    for palavra in resposta_simulada.split():
        yield f"{palavra} "

@app.post("/chat")
async def chat(request: PerguntaRequest):
    """Endpoint principal do chat, com verificação de cache antes de gerar."""
    # em um cenário real, aqui entraria a checagem de cache semântico
    # mostrada na seção anterior, antes de chamar o modelo

    return StreamingResponse(
        gerar_resposta_streaming(request.pergunta),
        media_type="text/plain",
    )

Para detalhes sobre StreamingResponse e outras formas de lidar com respostas assíncronas, a documentação oficial do FastAPI é a referência mais completa.

Escalando do MVP para produção

Algumas mudanças costumam marcar a transição de um MVP de IA para um produto em produção:

Sair de chamadas síncronas simples para filas de processamento, quando as tarefas de IA demoram mais que alguns segundos.

Adicionar observabilidade específica para IA, registrando prompt, resposta, latência e custo de cada chamada, não só logs de erro convencionais.

Definir limites de uso por plano antes que o custo de IA ultrapasse a receita gerada por aquele usuário.

Revisar prompts com a mesma disciplina que se revisa código, incluindo versionamento e testes.

Nenhuma dessas mudanças precisa acontecer no dia um, mas vale desenhar a arquitetura inicial já sabendo que elas vão chegar, para não precisar reescrever a camada de IA do zero quando o produto começar a crescer.

Próximos passos

Entender arquitetura, stack e custos é o primeiro passo, mas colocar tudo isso em prática, com estrutura de projeto real, integração de provedores de IA e boas práticas de engenharia, é o que separa um protótipo de um produto que realmente escala. Para quem quer aprofundar esses conhecimentos com uma formação estruturada, a Pós-graduação FullStack com IA da Rocketseat cobre desde a arquitetura de aplicações com IA até questões práticas de custo, performance e produção.

Arquitetura de um SaaS com IA

Um SaaS com IA bem estruturado costuma ser dividido em três camadas que conversam entre si, mas que podem escalar de forma independente.

Camada de aplicação

Camada de IA

Camada de dados

Stack completo: as escolhas que fazem sentido

Não existe uma stack única certa, mas existe um conjunto de decisões que se repete em produtos de IA que escalam bem.

Frontend

Backend e API

Orquestração de IA

Banco de dados e cache

Custos: onde o dinheiro vai embora

O custo de um SaaS com IA não é só "preço por token". Ele se divide em pelo menos três frentes.

Custo por token vs custo por usuário

Cache semântico para reduzir custos


# Exemplo simplificado de cache semântico usando Redis
# O objetivo é evitar chamar o modelo de IA para perguntas muito parecidas

import redis
import json
import numpy as np

cache = redis.Redis(host="localhost", port=6379, db=0)

def similaridade_cosseno(vetor_a: list[float], vetor_b: list[float]) -> float:
    """Calcula a similaridade entre dois embeddings."""
    a = np.array(vetor_a)
    b = np.array(vetor_b)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

def buscar_no_cache(embedding_pergunta: list[float], limite: float = 0.92) -> str | None:
    """Percorre as respostas em cache e retorna a mais parecida, se houver."""
    chaves = cache.keys("cache:pergunta:*")

    for chave in chaves:
        item = json.loads(cache.get(chave))
        score = similaridade_cosseno(embedding_pergunta, item["embedding"])

        if score >= limite:
            return item["resposta"]

    return None

def salvar_no_cache(pergunta: str, embedding: list[float], resposta: str):
    """Guarda a pergunta, o embedding e a resposta para reaproveitar depois."""
    chave = f"cache:pergunta:{hash(pergunta)}"
    valor = json.dumps({"embedding": embedding, "resposta": resposta})
    # expira em 24 horas, ajuste conforme o caso de uso do produto
    cache.setex(chave, 86400, valor)

Infraestrutura e hospedagem

Exemplo prático: endpoint de chat com streaming

Um exemplo de como estruturar um endpoint que recebe uma pergunta, verifica o cache e, se necessário, chama o modelo com streaming de resposta.


# Endpoint de exemplo usando FastAPI
# Recebe uma pergunta do usuário e retorna a resposta em streaming

from fastapi import FastAPI
from fastapi.responses import StreamingResponse
from pydantic import BaseModel

app = FastAPI()

class PerguntaRequest(BaseModel):
    pergunta: str
    usuario_id: str

async def gerar_resposta_streaming(pergunta: str):
    """Simula a geração de resposta em streaming, token por token."""
    # aqui entraria a chamada real ao provedor de IA,
    # usando o modo de streaming oferecido pela SDK dele
    resposta_simulada = "Aqui vai a resposta gerada pelo modelo de IA."

    for palavra in resposta_simulada.split():
        yield f"{palavra} "

@app.post("/chat")
async def chat(request: PerguntaRequest):
    """Endpoint principal do chat, com verificação de cache antes de gerar."""
    # em um cenário real, aqui entraria a checagem de cache semântico
    # mostrada na seção anterior, antes de chamar o modelo

    return StreamingResponse(
        gerar_resposta_streaming(request.pergunta),
        media_type="text/plain",
    )

Para detalhes sobre StreamingResponse e outras formas de lidar com respostas assíncronas, a documentação oficial do FastAPI é a referência mais completa.

Escalando do MVP para produção

Algumas mudanças costumam marcar a transição de um MVP de IA para um produto em produção:

Sair de chamadas síncronas simples para filas de processamento, quando as tarefas de IA demoram mais que alguns segundos.

Adicionar observabilidade específica para IA, registrando prompt, resposta, latência e custo de cada chamada, não só logs de erro convencionais.

Definir limites de uso por plano antes que o custo de IA ultrapasse a receita gerada por aquele usuário.

Revisar prompts com a mesma disciplina que se revisa código, incluindo versionamento e testes.

Próximos passos

Arquitetura de um SaaS com IA

Um SaaS com IA bem estruturado costuma ser dividido em três camadas que conversam entre si, mas que podem escalar de forma independente.

Camada de aplicação

Camada de IA

Camada de dados

Stack completo: as escolhas que fazem sentido

Não existe uma stack única certa, mas existe um conjunto de decisões que se repete em produtos de IA que escalam bem.

Frontend

Backend e API

Orquestração de IA

Banco de dados e cache

Custos: onde o dinheiro vai embora

O custo de um SaaS com IA não é só "preço por token". Ele se divide em pelo menos três frentes.

Custo por token vs custo por usuário

Cache semântico para reduzir custos


# Exemplo simplificado de cache semântico usando Redis
# O objetivo é evitar chamar o modelo de IA para perguntas muito parecidas

import redis
import json
import numpy as np

cache = redis.Redis(host="localhost", port=6379, db=0)

def similaridade_cosseno(vetor_a: list[float], vetor_b: list[float]) -> float:
    """Calcula a similaridade entre dois embeddings."""
    a = np.array(vetor_a)
    b = np.array(vetor_b)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

def buscar_no_cache(embedding_pergunta: list[float], limite: float = 0.92) -> str | None:
    """Percorre as respostas em cache e retorna a mais parecida, se houver."""
    chaves = cache.keys("cache:pergunta:*")

    for chave in chaves:
        item = json.loads(cache.get(chave))
        score = similaridade_cosseno(embedding_pergunta, item["embedding"])

        if score >= limite:
            return item["resposta"]

    return None

def salvar_no_cache(pergunta: str, embedding: list[float], resposta: str):
    """Guarda a pergunta, o embedding e a resposta para reaproveitar depois."""
    chave = f"cache:pergunta:{hash(pergunta)}"
    valor = json.dumps({"embedding": embedding, "resposta": resposta})
    # expira em 24 horas, ajuste conforme o caso de uso do produto
    cache.setex(chave, 86400, valor)

Infraestrutura e hospedagem

Exemplo prático: endpoint de chat com streaming

Um exemplo de como estruturar um endpoint que recebe uma pergunta, verifica o cache e, se necessário, chama o modelo com streaming de resposta.


# Endpoint de exemplo usando FastAPI
# Recebe uma pergunta do usuário e retorna a resposta em streaming

from fastapi import FastAPI
from fastapi.responses import StreamingResponse
from pydantic import BaseModel

app = FastAPI()

class PerguntaRequest(BaseModel):
    pergunta: str
    usuario_id: str

async def gerar_resposta_streaming(pergunta: str):
    """Simula a geração de resposta em streaming, token por token."""
    # aqui entraria a chamada real ao provedor de IA,
    # usando o modo de streaming oferecido pela SDK dele
    resposta_simulada = "Aqui vai a resposta gerada pelo modelo de IA."

    for palavra in resposta_simulada.split():
        yield f"{palavra} "

@app.post("/chat")
async def chat(request: PerguntaRequest):
    """Endpoint principal do chat, com verificação de cache antes de gerar."""
    # em um cenário real, aqui entraria a checagem de cache semântico
    # mostrada na seção anterior, antes de chamar o modelo

    return StreamingResponse(
        gerar_resposta_streaming(request.pergunta),
        media_type="text/plain",
    )

Para detalhes sobre StreamingResponse e outras formas de lidar com respostas assíncronas, a documentação oficial do FastAPI é a referência mais completa.

Escalando do MVP para produção

Algumas mudanças costumam marcar a transição de um MVP de IA para um produto em produção:

Sair de chamadas síncronas simples para filas de processamento, quando as tarefas de IA demoram mais que alguns segundos.

Adicionar observabilidade específica para IA, registrando prompt, resposta, latência e custo de cada chamada, não só logs de erro convencionais.

Definir limites de uso por plano antes que o custo de IA ultrapasse a receita gerada por aquele usuário.

Revisar prompts com a mesma disciplina que se revisa código, incluindo versionamento e testes.

Próximos passos

Conheça o Rocketseat Para Empresas

Oferecemos soluções personalizadas para empresas de todos os portes.

Rocketseat

Ecossistema de educação contínua referência em programação e Inteligência Artificial.

NewsletterReceba conteúdos inéditos e novidades gratuitamente

OFERTA