O Spec Driven Development (SDD) está ganhando destaque como uma abordagem inovadora para o desenvolvimento de software, especialmente em times que já utilizam inteligência artificial (IA) no dia a dia. Nesse artigo vou trazer um pouco das melhores práticas que venho utilizando e mostrar um exemplo prático de SKILL que me ajudou a estruturar melhor as especificações antes de gerar código com IA.

Acessar o artigo também no meu blog: Spec Driven Development: A abordagem que melhorou meu desenvolvimento com IA — Software Engineering

O que é Spec Driven Development?

A IA pode gerar grandes volumes de código, mas frequentemente sofre com a falta de contexto e alucinações, resultando em retrabalho para o desenvolvedor e um gasto desnecessário de tokens.

O SDD minimiza esse problema ao fornecer especificações claras e estruturadas. Ao invés de começar escrevendo código, começamos definindo:

• O problema
• As regras de negócio
• Fluxos
• Requisitos funcionais
• Requisitos não funcionais
• Critérios de aceite
• Estrutura técnica
• Limitações
• Edge cases

Principais benefícios do SDD

• Menos retrabalho: Com especificações claras, a IA tem menos chances de gerar código que não atende aos requisitos, reduzindo a necessidade de correções.
• Melhor comunicação: O SDD promove uma comunicação mais eficaz entre os membros da equipe, garantindo que todos estejam alinhados quanto aos objetivos do projeto.
• Aumento da produtividade: Com menos retrabalho e melhor comunicação, os times podem se concentrar em tarefas mais estratégicas, aumentando a eficiência geral.
• Melhoria na qualidade do código: Especificações bem definidas ajudam a garantir que o código gerado esteja dentro das boas práticas do time/projeto.

Estes são os principais benefícios, mas conforme a prática vai ficando mais madura dentro do time, outros benefícios vão surgindo, como a facilidade de onboarding de novos membros, a documentação automática do projeto e a redução de dívidas técnicas.

Como funciona na prática?

1. Definição das especificações: O time define as especificações do projeto de forma clara e detalhada, utilizando uma linguagem que a IA possa entender facilmente.
2. Validação das especificações: As especificações são revisadas e validadas para garantir que estejam completas e corretas.
3. Implementação: A IA gera o código com base nas especificações fornecidas, e os desenvolvedores revisam o código para garantir que atenda aos requisitos.
4. Validação: Após o código ser gerado, ele é testado e validado para garantir que funcione conforme esperado. (Aqui está o tempo que foi economizado anteriormente.)

Como estruturar uma SKILL para geração de SDD

Uma skill é um prompt de sistema especializado, associado a um comando (como /spec-driven-build), que guia a IA por um fluxo estruturado de perguntas e geração de artefatos. Em vez de você descrever o processo a cada conversa, a skill carrega esse contexto automaticamente — e fica versionada no próprio repositório.

O ponto central de uma boa skill de SDD é o fluxo em fases. Cada fase tem uma responsabilidade clara e só avança com a aprovação explícita do desenvolvedor.

Caso queira testar, gerei uma skill que utilizo no dia a dia para criar SDDs para meus projetos pessoais. Você pode ver o código completo dela aqui: jjeanjacques10/skills/spec-driven-build/SKILL.md

Abaixo mostro a estrutura que proponho caso queira criar uma SKILL semelhante para seu time:

Output esperado

Dentro da pasta docs/<feature>/ do projeto, a skill deve gerar:

docs/<feature>/
    ├── SDD.md
    └── tasks/
         ├── TASK-1-<descricao-em-kebab-case>.md
         ├── TASK-2-<descricao-em-kebab-case>.md
         └── TASK-N-verificacao-e2e.md

Etapas do processo

Fase 0 — Coleta de contexto

Antes de escrever qualquer arquivo, a skill deve fazer perguntas direcionadas para eliminar ambiguidades:

1. O que precisa ser corrigido ou implementado?
2. Qual é o impacto ou risco se não for feito?
3. Quais arquivos ou áreas do código já foram identificados como afetados?
4. Há restrições ou decisões já tomadas?

Fase 1 — Geração do SDD

Com o contexto em mãos, a skill deve explorar o código do projeto com ferramentas reais antes de escrever qualquer linha do documento. O SDD gerado deve referenciar arquivos existentes, números de linha, interfaces e funções — nunca ser genérico.

A estrutura ideal do SDD.md tem sete seções fixas:

SeçãoConteúdo1. Contexto e ProblemaEstado atual + risco ou motivação (máx. 3 parágrafos)2. Escopo da CorreçãoO que muda × o que não muda (tabela + lista explícita)3. Design da SoluçãoDescrição técnica por módulo/componente com snippets prontos4. Fluxo após a correçãoDiagrama ASCII do novo fluxo de dados ou de usuário5. Arquivos a modificar/criarTabela de impacto com tipo de mudança6. Critérios de AceiteChecklist objetivo e verificável7. Considerações adicionaisSegurança, performance, débito técnico (omitir se vazio)

Fase 2 — Validação do SDD

Antes de apresentar o documento ao desenvolvedor, a skill deve fazer uma auto-revisão com um checklist interno:

• Todos os arquivos da seção 5 existem no projeto (ou são explicitamente novos)?
• Os snippets são compatíveis com as versões de biblioteca usadas no projeto?
• Os critérios de aceite são verificáveis objetivamente?
• O escopo está claro e sem ambiguidade entre o que muda e o que não muda?

Após a revisão, apresentar ao desenvolvedor um resumo de 3–5 linhas e aguardar aprovação antes de avançar.

Fase 3 — Geração das Tasks

Com o SDD aprovado, a skill cria arquivos individuais de task em docs/<feature>/tasks/. A nomenclatura segue o padrão:

TASK-1-<descricao-em-kebab-case>.md
TASK-2-<descricao-em-kebab-case>.md
...
TASK-N-verificacao-e2e.md   ← sempre a última

Cada arquivo de task deve conter:

• Arquivo-alvo com caminho completo (novo ou existente)
• Referência à seção do SDD que originou aquela task
• Dependências explícitas (Depende de: TASK-X ou nenhuma)
• Contexto — por que a task existe e o que está errado hoje
• O que fazer — com before/after quando for modificar código existente
• Notas de implementação — armadilhas, decisões não óbvias, efeitos colaterais
• Critério de aceite — checklist verificável

Fase 4 — Resumo final

A skill encerra apresentando o mapa completo de execução com as dependências e o paralelismo possível:

✓ SDD:   docs/<feature>/SDD.md
✓ Tasks: docs/<feature>/tasks/
   TASK-1 — Criar hook de contexto        [independente]
   TASK-2 — Adicionar guard de rota       [após TASK-1]
   TASK-3 — Atualizar componente de menu  [após TASK-1, paralelo com TASK-2]
   TASK-4 — Verificação e2e              [última]

Paralelas: TASK-2 e TASK-3 podem ser executadas simultaneamente.

Exemplo de como ficou em um projeto real:

Como estruturar um bom SDD

O maior erro ao escrever um SDD é focar no “o quê” e esquecer o “por quê” e o “o que não muda”. Veja os princípios que fazem um SDD realmente funcionar:

Seja cirúrgico no escopo. Um SDD que tenta resolver mais de um problema ao mesmo tempo vira uma fonte de confusão. Se durante a escrita você perceber que algo adjacente também deveria ser corrigido, crie um segundo SDD separado.

Referencie o código real. “Adicionar validação no formulário” é vago. “Adicionar validação na função handleSubmit em src/routes/login.tsx, linha ~83, usando o schema Zod existente em src/lib/schemas.ts” é um SDD. A IA implementa o segundo sem perguntas.

Escreva snippets completos. Pseudocódigo cria margem para interpretação. Snippets compiláveis eliminam suposições e são a principal razão pela qual a IA gera código correto na primeira tentativa.

Use a seção “O que não muda” como cerca elétrica. Liste explicitamente o que está fora do escopo. Isso instrui a IA a não refatorar, não renomear, não mover arquivos que não foram solicitados. É a seção que mais reduz retrabalho na prática.

Critérios de aceite verificáveis. Cada critério deve ser uma afirmação que pode ser marcada como verdadeira ou falsa após a implementação. “O sistema deve funcionar bem” não é um critério — “O banner não aparece se o usuário já aceitou os cookies na sessão anterior” é.

Exemplo

Você pode ver a skill completa utilizada neste projeto aqui: jjeanjacques10/skills/spec-driven-build/SKILL.md

Ferramentas para SDD

Claude Code (Skills customizadas) A abordagem descrita neste artigo: skills são prompts de sistema associados a comandos (/spec, /review, etc.) que ficam versionados no próprio repositório em .claude/skills/. Funcionam como “especialistas contextuais” que entendem a estrutura e convenções do seu projeto específico.

Kiro — AWS O Kiro vai em uma abordagem de a própria IDE apoia no processo de SDD, guiando o desenvolvedor por perguntas estruturadas e gerando artefatos organizados. Ele é mais opinativo e menos customizável que uma skill personalizada, mas pode ser uma boa opção para times que buscam uma solução pronta.

Cursor / GitHub Copilot Workspace Ferramentas de IDE com geração de planos antes do código. O Copilot Workspace cria um “plan” editável antes de propor implementações — uma aproximação da ideia de SDD, mas sem a estrutura formal de documento e tasks separadas.

SpecFlow (BDD para .NET) Framework que usa a sintaxe Gherkin (Given / When / Then) para escrever especificações legíveis por não-desenvolvedores. Mais voltado a testes de aceitação automatizados do que à fase de design, mas compartilha o princípio de “especificar antes de implementar”.

Conclusão

O Spec Driven Development representa uma evolução na forma como desenvolvemos software no dia a dia, saindo do tradicional prompt one-shot e adotando uma abordagem mais estruturada e eficiente. A qualidade de uma especificação determina diretamente a qualidade do código gerado — e uma boa skill automatiza exatamente isso: guiar a IA pelo processo certo antes de qualquer linha de código ser escrita.

Ao implementar o SDD, os times podem reduzir retrabalho, melhorar a comunicação e aumentar a produtividade, resultando em projetos de maior qualidade e sucesso.

Compartilhe com seu time e experimente essa nova abordagem. Depois me conta os resultados!

Obrigado por lerem!

Referências

• Documentação oficial do Claude Code sobre Skills personalizadas
• Site oficial do SpecFlow, framework de BDD para .NET
• Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl

Para quem trabalha com arquiteturas distribuídas e comunicações assíncronas, esse cenário é bem comum:

Preciso controlar quantas mensagens devem ser processadas ao mesmo tempo pelos consumidores, para evitar o uso excessivo de recursos ou para seguir alguma regra de negócio específica.

Para resolver esse tipo de problema, temos algumas estratégias interessantes que podemos utilizar. É exatamente isso que quero trazer neste artigo, além da aplicação de exemplo que criei para validar cada um dos cenários:

• https://github.com/jjeanjacques10/rate-limit-hero-orders

O problema

Inspirado no universo de My Hero Academia, onde super-heróis recebem solicitações de serviço através de uma fila SQS, precisamos de controle, coordenação e limites para não causar problemas de excesso de requisições.

Cenário:

• Centenas de solicitações de heróis chegam simultaneamente
• Vários “escritórios de heróis” (containers) processam mensagens em paralelo
• Cada solicitação exige processamento confiável (nenhuma pode ser perdida)
• O sistema não pode sobrecarregar recursos críticos

Vamos agora explorar algumas estratégias para resolver esse problema…

🏗️Estratégia 1: Controle na aplicação (local)

Esta é a abordagem mais simples, onde o controle é feito dentro da própria aplicação/agência, limitando o que cada container individual pode fazer.

Como funciona

Configuramos o listener do SQS para processar um número fixo de mensagens por vez. No Spring Cloud AWS, usamos as propriedades maxConcurrentMessages e maxMessagesPerPoll. Cada escritório de super-heróis faz seu próprio controle. No exemplo abaixo, são 3 solicitações por vez:

@SqsListener(
    value = ["event-hero-orders-queue"],
    maxConcurrentMessages = "3",
    maxMessagesPerPoll = "3"
)
fun consumeMessage(message: Message<HeroOrderRequest>, acknowledgement: Acknowledgement) {
    try {
        orderService.processOrder(message.payload)
        acknowledgement.acknowledge() // Confirmação manual
    } catch (e: Exception) {
        // Se falhar, volta para a fila automaticamente (validar maxReceiveCount)
    }
}

Em cenários de rate limit ou backpressure intencional (Token Bucket ou Semáforo), a mensagem pode retornar várias vezes para a fila sem representar erro. Caso a fila tenha DLQ configurada, é necessário ajustar o maxReceiveCount para evitar que mensagens válidas sejam enviadas indevidamente para a DLQ apenas por falta momentânea de capacidade.

Vantagem

• ✔ Simples de implementar
• ✔ Não depende de componentes externos

Desvantagem

• ❌ Não escala bem
• ❌ Não existe uma visão global do limite

Se você tiver 10 containers com limite de 3 mensagens, terá 30 mensagens sendo processadas simultaneamente, independentemente da capacidade real do sistema.

Cenário não recomendado

• ❌ Quando o número de containers escala dinamicamente

Execução

Exemplo de itens sendo processados, de 3 em 3, com cada solicitação durante 5 segundos:

> ./mvnw spring-boot:run -Dspring.profiles.active=local-control

Agora podemos entrar um pouco em estratégias que funcionam melhor em cenários distribuídos:

🚥 Estratégia 2: Semáforos Distribuídos (Redis)

Quando precisamos garantir que, independente do número de escritórios de heróis (containers), apenas um certo número de solicitações sejam processadas simultaneamente no cluster todo, podemos usar um Semáforo Distribuído.

O Conceito

Definimos o Redis como uma fonte da verdade. Antes de processar a mensagem, o consumidor tenta adquirir um “permissão” (permit).

1. O consumidor busca a mensagem no SQS.
2. Tenta adquirir o permit no Redis.
3. Conseguiu? Processa e, ao final, libera o permit.
4. Não conseguiu? A mensagem não é confirmada (no-ACK) e volta para a fila para ser tentada novamente por outro (ou pelo mesmo) container.

@SqsListener(
    value = ["event-hero-orders-queue"],
    acknowledgementMode = "MANUAL",
    id = "distributed-semaphores-order-consumer"
)
fun consumeMessage(message: Message<HeroOrderRequest>, acknowledgement: Acknowledgement) {
    var permitId: String? = null

    try {
        // Tenta adquirir uma permissão do semáforo distribuído
        permitId = distributedSemaphore.tryAcquire(message.payload.heroId)

        if (permitId == null) {
            // Não foi possível adquirir permissão, rejeita a mensagem para ser retentada depois
            log.warn("Could not acquire semaphore permit for order: ${message.payload.heroName}. Message will NOT be acknowledged (returning to queue).")
            // NÃO faz o acknowledge - a mensagem retornará à fila
            return
        }

        // Processa o pedido com a permissão
        orderService.processOrder(message.payload)

        // Faz o acknowledge da mensagem apenas após o processamento bem-sucedido
        acknowledgement.acknowledge()
        log.info("Message acknowledged successfully for hero: ${message.payload.heroName}")
    } catch (e: Exception) {
        // Se o processamento falhar, NÃO faz acknowledge - a mensagem retornará à fila
        log.error("Error processing message for hero: ${message.payload.heroName}. Message will NOT be acknowledged.", e)
        // A mensagem retornará automaticamente à fila
    } finally {
        // Sempre libera a permissão se ela foi adquirida
        permitId?.let {
            distributedSemaphore.release(it)
        }
    }
}

Ponto Chave: O uso de TTL (Time-To-Live) nos permits do Redis garante que, se um container morrer, a permissão expire e não trave o sistema indefinidamente.

Cenário não recomendado

• ❌ Não usar para controle de taxa (ex: requisições por minuto)
• ❌ Não usar sem TTL (risco real de deadlock distribuído)

Execução

Exemplo de itens sendo processados conforme os recursos são liberados:

> ./mvnw spring-boot:run -Dspring.profiles.active=distributed-semaphores

🪣 Estratégia 3: Token Bucket Distribuído

Se o seu problema não é apenas a concorrência (quantos agora), mas sim a taxa de transferência (quantos por segundo), o algoritmo Token Bucket é a escolha ideal. Esse é o que mais vejo ser implementado no dia a dia!

Como funciona

Imagine um balde que se enche de “tokens” a uma taxa constante (ex: 2 tokens por segundo). Para processar uma mensagem, o consumidor precisa retirar um token do balde, para um novo serviço ser processado é necessário que os heróis estejam disponíveis para isso.

• Burst: Se o balde estiver cheio (ex: 10 tokens), o sistema pode processar 10 mensagens.
• Refill: Após o pico, ele volta a processar apenas na velocidade em que os tokens são repostos (2/s).

fun tryConsume(tokensNeeded: Int = 1): Boolean {
    refillTokens() // Reabastece tokens baseado no tempo
    
    val currentTokens = getCurrentTokens()
    if (currentTokens >= tokensNeeded) {
        // Consome o token atomicamente
        redisTemplate.opsForValue().decrement(TOKEN_BUCKET_KEY, tokensNeeded.toLong())
        return true
    }
    return false
}

Com isso o consumidor segue o seguinte formato:

@SqsListener(
    value = ["event-hero-orders-queue"],
    acknowledgementMode = "MANUAL",
    id = "distributed-token-bucket-order-consumer"
)
fun consumeMessage(message: Message<HeroOrderRequest>, acknowledgement: Acknowledgement) {
    try {
        // Tenta consumir um token do bucket
        if (!tokenBucket.tryConsume()) {
            // Nenhum token disponível, rejeita a mensagem para ser retentada depois
            log.warn("No token available for order: ${message.payload.heroName}. Message will NOT be acknowledged (returning to queue).")
            // NÃO faz o acknowledge - a mensagem retornará à fila
            return
        }

        // Processa o pedido se o token foi consumido
        orderService.processOrder(message.payload)

        // Faz o acknowledge a mensagem apenas após o processamento bem-sucedido
        acknowledgement.acknowledge()
        log.info("Message acknowledged successfully for hero: ${message.payload.heroName}")
    } catch (e: Exception) {
        // Se o processamento falhar, NÃO faz acknowledge - a mensagem retornará à fila
        log.error("Error processing message for hero: ${message.payload.heroName}. Message will NOT be acknowledged.", e)
        // A mensagem retornará automaticamente à fila
    }
}

Cenário não recomendado

• ❌ Não usar quando o problema é concorrência simultânea
• ❌ Evitar usar sem que a operação seja atômica (como no exemplo acima).

Execução

Processamentos sendo feitos com o uso de token bucket, muitas transações retornam para fila aguardando a liberação de mais fichas no balde.

🪣 Estratégia 4: Token Bucket Distribuído com Bucket4J

As implementações acima foram feitas de forma manual, vamos explorar um pouco uma solução de mercado para isso. Uma das mais famosas é o Bucket4J, uma biblioteca Java para rate limit baseada no algoritmo de token-bucket. Mas antes quero falar um pouco dos motivos que resolvi trazer essa solução para esse artigo a “Atomicidade”:

Atomicidade

Atomicidade garante que a operação de verificar a quantidade de tokens disponível e consumi-los aconteça como uma única operação indivisível.

Ou tudo acontece, ou nada acontece.

Sem atomicidade, o sistema fica vulnerável a race conditions, como no exemplo abaixo:

• Dois consumidores leem simultaneamente que há 1 token disponível
• Ambos acreditam que podem processar a mensagem
• Ambos decrementam o contador
• O limite é violado e mais mensagens são processadas do que o permitido

Na primeira implementação de token bucket não tínhamos essa garantia, por serem múltiplos comandos do Redis, não uma única transação atômica. Isso significa que dois ou mais consumidores podem intercalar operações e violar o limite do balde. A lib do Bucket4j usa uma estratégia CAS (comparar e trocar) sobre um único estado de bucket serializado no Redis.

Configurando o bucket4j

Configuração do Bucket4J, preferi separar em uma classe de configuração nesse caso:

@Configuration
class BucketConfig(
    @Value("\${spring.data.redis.host:localhost}") private val redisHost: String,
    @Value("\${spring.data.redis.port:6379}") private val redisPort: Int,
    @Value("\${spring.data.redis.password}") private val redisPassword: String
) {

    @Bean
    fun bucket4jRedisClient(): RedisClient {
        val redisUri = if (redisPassword.isNotBlank()) {
            "redis://$redisPassword@$redisHost:$redisPort"
        } else {
            "redis://$redisHost:$redisPort"
        }
        return RedisClient.create(redisUri)
    }

    @Bean
    fun bucket4jRedisConnection(redisClient: RedisClient): StatefulRedisConnection<String, ByteArray> {
        return redisClient.connect(RedisCodec.of(StringCodec.UTF8, ByteArrayCodec.INSTANCE))
    }

    @Bean
    fun bucket4jProxyManager(connection: StatefulRedisConnection<String, ByteArray>): ProxyManager<String> {
        return LettuceBasedProxyManager.builderFor(connection).build()
    }

    @Bean
    fun bucket4jConfigurationConfig(): BucketConfiguration {
        return BucketConfiguration.builder()
            .addLimit { limit ->
                limit.capacity(MAX_TOKENS)
                    .refillGreedy(REFILL_TOKENS, Duration.ofSeconds(REFILL_PERIOD_SECONDS))
            }.build()
    }

    @Bean
    fun bucket(proxyManager: ProxyManager<String>, bucketConfiguration: BucketConfiguration): Bucket {
        val bucket = proxyManager.builder().build(BUCKET_KEY) { bucketConfiguration }
        log.info("Bucket4j initialized with capacity: $MAX_TOKENS tokens, refill rate: $REFILL_TOKENS tokens per $REFILL_PERIOD_SECONDS second(s)")
        return bucket
    }

    companion object {
        val log: Logger = LoggerFactory.getLogger(this::class.java)
        const val BUCKET_KEY = "hero:orders:bucket4j:token_bucket"
        const val MAX_TOKENS = 10L // Capacidade máxima do bucket
        const val REFILL_TOKENS = 2L // Tokens adicionados
        const val REFILL_PERIOD_SECONDS = 1L // Período de reabastecimento (1 segundo)
    }
}

Com isso o controle fica no service da aplicação, validando se existem tokens válidos para uso naquele momento.

@Service
class RedisDistributedTokenBucket4j(
    private val bucket: Bucket
) {

    /**
     * Tenta consumir um token do bucket
     * @param tokensNeeded número de tokens necessários (padrão 1)
     * @return true se o(s) token(s) foi(ram) consumido(s), false caso contrário
     */
    fun tryConsume(tokensNeeded: Long = 1): Boolean {
        val consumed = bucket.tryConsume(tokensNeeded)

        if (consumed) {
            val availableTokens = bucket.availableTokens
            log.info("Token(s) consumed: $tokensNeeded. Available tokens: $availableTokens/$MAX_TOKENS")
        } else {
            val availableTokens = bucket.availableTokens
            log.warn("Not enough tokens available. Current: $availableTokens/$MAX_TOKENS, Needed: $tokensNeeded")
        }

        return consumed
    }

    companion object {
        val log: Logger = LoggerFactory.getLogger(this::class.java)
    }
}

Vantagem

• ✔ Não há race conditions, o CAS (Compare-And-Set) garante atomicidade
• ✔ Fácil de configurar, com uma API simples e intuitiva
• ✔ Testado em produção por milhares de empresas

Sempre é bom considerar “opções de mercado” com soluções já prontas, onde a “roda” não precisa ser reimplementada.

Execução

Exemplo de itens sendo processados utilizandos os tokens no bucket:

> ./mvnw spring-boot:run -Dspring.profiles.active=distributed-token-bucket4j

📊 Semáforo vs. Token Bucket

Colocando as duas opções lado a lado:

💡 Conclusão

Não existe “bala de prata” para rate limit.

• Se o controle é simples e o número de instâncias é fixo, um controle a nível de aplicação resolve!
• Se temos uma limitação relacionada a quantos itens simultâneos precisam ser processados, por exemplo, caso seu banco de dados não aguenta mais de 10 conexões simultâneas, use Semáforos.
• Se o controle precisa ser quantos processos são permitidos, como 100 itens por minuto, vá de Token Bucket.
• Mesmo que seja possível implementar soluções próprias, sempre busque utilizar soluções de mercado se possível.

O segredo está em entender o gargalo do seu sistema e escolher a estratégia que melhor protege seus recursos sem sacrificar a resiliência.

Caso tenha alguma crítica, sugestão ou dúvida fique à vontade para me enviar uma mensagem:

LinkedIn: https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Referências

• System Design — API Gateway | Matheus Fidelis (Token Bucket)
• Você Sabe o que é Token Bucket? Entenda de Forma Simples
• jjeanjacques10/rate-limit-hero-orders

Em algum momento pode ser que apareça uma tarefa em seu trabalho onde precise criar uma integração com o Kafka, quando você começa a desenvolver sua aplicação, criar sua lógica de negócio e então se de para com o arquivo cheio de parâmetros surgindo a pergunta: “Quais configurações devo fazer aqui que fazem sentido para o meu cenário?”.

É comum esse tipo de questionamento, kafka como uma ferramenta robusta nos oferece diversos recursos e configurações, e é importante entender como cada uma delas pode ser utilizada para atender as necessidades do seu projeto. Vamos entender um pouco mais sobre o Kafka e trazer exemplos práticos de como você pode preencher esses parâmetros da melhor forma sem precisar “chutar” o que pode ou não ser o melhor para o seu cenário.

O que é o Kafka

Kafka é uma plataforma de streaming distribuída desenvolvida pelo LinkedIn em 2011 e posteriormente, foi doada para a Apache Software Foundation, que hoje cuida da ferramenta. Nasceu da necessidade de lidar com fluxos de dados em tempo real de forma escalável, durável e tolerante a falhas, tornando-se uma peça fundamental em arquiteturas modernas de processamento de dados com a capacidade de processar trilhões de mensagens por dia. Em exemplos reais, Kafka pode ser utilizado para:

• Streaming de Dados em tempo real
• Monitoramento e Alertas
• Processamento de Big Data
• Integração entre Microsserviços

Tópicos

Tópicos são utilizados para organizar o fluxo de dados no Kafka, onde os registros são armazenados na sequência em que foram gerados, vamos entrar em detalhes mais a frente de como isso funciona. Por exemplo, uma aplicação de processamento de pagamentos pode ter tópicos como “transacoes-cartao”, “transacoes-boletos” e “transacoes-pix”, cada um representando um tipo diferente de transação financeira.

Tópicos vs Filas: Ao discutir tópicos no Kafka, muitas vezes surge a dúvida sobre a diferença entre eles e as filas. Em uma fila, as mensagens são consumidas sequencialmente por um único consumidor, garantindo o processamento FIFO (First In, First Out). Por outro lado, em um tópico, segue-se o modelo publish/subscribe, onde cada mensagem publicada é consumida por todos os consumidores registrados no tópico. Além disso, são utilizadas técnicas de particionamento para garantir a escalabilidade na leitura das mensagens pelos grupos de consumidores.

Brokers

Os brokers no Kafka são os servidores encarregados de armazenar e gerenciar os dados dos tópicos. Cada broker é parte de um cluster Kafka e mantém uma cópia dos dados dos tópicos aos quais está atribuído. Eles são escaláveis e podem ser adicionados ou removidos do cluster conforme necessário para aumentar a capacidade ou a disponibilidade do sistema.

Partições (Partitions)

Partições são segmentações que permitem dividir o tópico em frações menores; novas mensagens são adicionadas a uma partition.

Cada partição possui offsets, que são a identificação da mensagem dentro de uma partição específica, o que ajuda a saber a ordem em que foram recebidas e que devem ser processadas. Serem separadas por offsets facilita na hora de processar as mensagens, pois é possível configurar para que sejam lidas a partir de um offset específico, como em casos de reprocessamento, regras de negócio que precisem “voltar no tempo” para processar mensagens antigas ou onde queremos apenas ler mensagens de um determinado ponto.

Utilizar várias partições garante desempenho com grandes cargas de trabalho, aproveitando a replicação e a distribuição de carga entre os brokers. Por exemplo, se um tópico tiver 3 partições e 3 consumidores, cada consumidor lerá de uma partição diferente, garantindo que as mensagens sejam processadas de forma paralela.

Avro

O Kafka transfere bytes de um local para outro, Avro é uma solução para garantir o contrato nessa comunicação. Ele é uma ferramenta de serialização/deserialização de dados que define o formato das mensagens que serão enviadas e recebidas. Além disso, ele permite definir esquemas para os dados transferidos, o que auxilia na garantia de que os dados sejam interpretados corretamente pelos consumidores, mesmo quando os esquemas evoluem ao longo do tempo.

Aqui está um exemplo de um esquema Avro que define um objeto chamado TransactionItem:

{
  "type": "record",
  "name": "TransactionItem",
  "namespace": "com.payment",
  "fields": [
    {
      "name": "value",
      "type": "string"
    },
    {
      "name": "origin",
      "type": {
        "type": "record",
        "name": "Origin",
        "fields": [
          {
            "name": "account",
            "type": "string"
          }
        ]
      }
    },
    {
      "name": "createdAt",
      "type": {
        "type": "string"
      }
    }
  ]
}

Importante lembrar que o Avro não é obrigatório, mas é uma boa prática utilizá-lo para garantir a compatibilidade entre as mensagens enviadas e recebidas.

Além dos exemplos mencionados anteriormente, existem muitas outras aplicações para essa ferramenta. Neste artigo, vamos nos concentrar na comunicação entre microsserviços. Nosso exemplo será um sistema de pagamentos que processa transações PIX e notifica os clientes quando tudo ocorrer com sucesso!

Todos os exemplos apresentados neste artigo podem ser encontrados no seguinte repositório no GitHub: jjeanjacques10/payment-async-kafka: This is a payment system that utilizes Kafka technology for asynchronous integration

Producer

O producer Kafka é responsável por gerar as mensagens e publicá-las nos tópicos. É possível ter diversos producers publicando mensagens em um mesmo tópico, e também é possível ter diversos producers publicando mensagens em tópicos diferentes. Para evitar de perder mensagens, lembre-se de configurar o “acks”, que define o número de replicas que devem confirmar o recebimento da mensagem, e também o “retries”, que define o número de tentativas que o producer deve realizar para enviar a mensagem.

Aqui está um exemplo de configuração para um produtor em Spring, onde as principais configurações estão relacionadas à forma como queremos enviar as mensagens.

spring:
  application.name: pix-processor
  kafka:
    producer:
      bootstrap-servers: localhost:9092
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: io.confluent.kafka.serializers.KafkaAvroSerializer
      compression-type: snappy # Configura o tipo de compressão que deve ser aplicado às mensagens
      acks: all # Configura o acks para "all" para garantir que todas as réplicas confirmem o recebimento da mensagem
      retries: 3 # Configura o número de tentativas que o producer deve realizar para enviar a mensagem
    template:
      default-topic: payment-topic

• bootstrap-servers: Define os endpoints utilizados para se conectar com o cluster Kafka. Ex: bootstrap-servers=kafka1:9092,kafka2:9092
• key-serializer: Classe responsável pela serialização das chaves das mensagens produzidas. Ex: key-deserializer=org.apache.kafka.common.serialization.StringDeserializer
• value-serializer: Classe responsável pela serialização dos valores das mensagens produzidas, ele define o formato que os consumidores devem seguir. Ex: key-deserializer=io.confluent.kafka.serializers.KafkaAvroSerializer
• properties.schema.registry.url: URL do registro de esquemas utilizado para registrar e recuperar esquemas. Ex: schema.registry.url=http://localhost:8082 (exemplo para configuração local)
• auto.register.schemas: Indica se os esquemas que ainda não existem devem ser registrados automaticamente no schema registry. Ex: auto.register.schemas=false
• retries: Número de tentativas que o produtor deve realizar para enviar a mensagem. Ex: retries=3

acks

O “acks” é uma propriedade que define o número de réplicas que devem confirmar o recebimento da mensagem. Existem três valores possíveis para essa propriedade:

• 0: O produtor não aguarda nenhuma confirmação.
• 1: O produtor aguarda a confirmação do líder da partição.
• all: O produtor aguarda a confirmação de todas as réplicas da partição.

value-serializer

Um dos pontos principais a serem configurados no produtor é o “value-serializer”, que define como os valores das mensagens serão serializados. No exemplo acima, o “value-serializer” está configurado como “io.confluent.kafka.serializers.KafkaAvroSerializer”, que é um serializador Avro.

• io.confluent.kafka.serializers.KafkaAvroDeserializer
• org.apache.kafka.common.serialization.StringSerializer
• org.apache.kafka.common.serialization.ByteArraySerializer

compression-type

O “compression-type” é uma propriedade que define o tipo de compressão que deve ser aplicado às mensagens. Existem alguns tipos de compressão disponíveis, como:

• none: Sem compressão.
• gzip: Compressão GZIP.
• snappy: Compressão Snappy.
• lz4: Compressão LZ4.

Consumer

Os consumidores são aqueles que se conectam aos nossos tópicos para ler as mensagens publicadas pelos produtores. É possível ter diversos consumers conectados a um tópico. Para evitar a leitura de mensagens repetidas, lembre-se de configurar o “group-id”, definindo que o novo consumidor faz parte de um grupo único e que realiza o mesmo processo e também realiza o “acknowledging” que remove a mensagem da fila para o grupo definido. É utilizado o offset para controlar a leitura das mensagens, garantindo que as mensagens sejam lidas apenas uma vez por aquele grupo consumidor (group-id).

Aqui está um exemplo de configuração para um consumidor em Spring, onde as principais configurações estão relacionadas à forma como queremos receber as mensagens e como elas devem ser tratadas.

spring:
  application.name: notification
  kafka:
    consumer:
      bootstrap-servers: localhost:9092
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: io.confluent.kafka.serializers.KafkaAvroDeserializer
      group-id: notification-payment-group
      properties:
        auto.offset.reset: earliest # ou 'latest'
    listener:
      ack-mode: MANUAL_IMMEDIATE
    template:
      default-topic: payment-topic
    properties:
      spring.deserializer.key.delegate.class: org.apache.kafka.common.serialization.StringDeserializer
      spring.deserializer.value.delegate.class: io.confluent.kafka.serializers.KafkaAvroDeserializer
      spring.deserializer.value.fail-on-unknown-type: false
      spring.deserializer.value.type: io.confluent.kafka.serializers.subject.RecordNameStrategy
      schema.registry.url: http://localhost:8082
      specific.avro.reader: true # Deserialize to the generated Avro class rather than a GenericRecord type
      auto.register.schemas: false # Whether schemas that do not yet exist should be registered

Existem tantas configurações que seria difícil descrevê-las todas neste artigo, então vou focar em algumas das propriedades que costumo adicionar em minhas configurações, busque entender o que faz mais sentido para o seu cenário.

• key-deserializer: Classe responsável pela desserialização das chaves das mensagens consumidas. Ex: key-deserializer=org.apache.kafka.common.serialization.StringDeserializer
• value-deserializer: Classe responsável pela desserialização dos valores das mensagens consumidas. Ex: value-deserializer=io.confluent.kafka.serializers.KafkaAvroDeserializer
• group-id: Identificador do grupo de consumidores ao qual este consumidor pertence. Ex: group-id=pix-consumer-group
• properties.spring.deserializer.key.delegate.class: Classe delegada responsável pela desserialização das chaves das mensagens, utilizada para configurações específicas do Spring. Ex: spring.deserializer.key.delegate.class=org.apache.kafka.common.serialization.StringDeserializer
• properties.spring.deserializer.value.delegate.class: Classe delegada responsável pela desserialização dos valores das mensagens, utilizada para configurações específicas do Spring. Ex: spring.deserializer.value.delegate.class=io.confluent.kafka.serializers.KafkaAvroDeserializer
• properties.spring.deserializer.value.fail-on-unknown-type: Indica se deve falhar ao desserializar um tipo desconhecido. Pode auxiliar em cenários onde o esquema é desconhecido. Ex: spring.deserializer.value.fail-on-unknown-type=false
• properties.spring.deserializer.value.type: Estratégia para obter o nome do registro do esquema para um determinado valor, usado em conjunto com o Schema Registry. Ex: spring.deserializer.value.type=io.confluent.kafka.serializers.subject.RecordNameStrategy
• specific.avro.reader: Indica se a desserialização deve ser feita para a classe Avro gerada específica ou para o tipo GenericRecord. Ex: specific.avro.reader=true

ack-mode

O “ack-mode” é uma propriedade que define como o consumidor deve confirmar o recebimento da mensagem. Existem três modos de confirmação:

• RECORD: Confirmação de registro por registro.
• BATCH: Confirmação de registros em lote.
• MANUAL: Confirmação manual.
• MANUAL_IMMEDIATE: Confirmação manual imediata.

No exemplo abaixo, o “ack-mode” está configurado para MANUAL_IMMEDIATE, ou seja, a confirmação é feita manualmente e imediatamente após o processamento da mensagem.

try {
    log.info("Consume Kafka message - topic: {}, offset: {}, partition: {}", topic, offset, partition)
    notificationService.process(transactionItem.toTransaction())
} catch (
ex: `Exception) {`
    log.error("Error processing message: {}", ex.message, ex)
} finally {
    ack.acknowledge() // Confirmação manual sendo realizada
}

consumer.properties.auto.offset.reset

No Kafka, as configurações “earliest” e “latest” são usadas para determinar onde o consumidor deve começar a consumir mensagens.

• earliest: Quando o deslocamento da partição não está presente (por exemplo, quando o grupo de consumidores está consumindo a partição pela primeira vez), o consumidor começará a consumir a partir do início da partição.
• latest: Quando o deslocamento da partição não está presente, o consumidor começará a consumir a partir do final da partição, ou seja, ele não consumirá nenhuma mensagem que já esteja na partição no momento em que começou a consumir.

Boas práticas

É uma boa prática adiciona o log do offset e também a partition que está lendo, isso pode auxiliar na análise futura do problema de ambos os lados, tanto no consumer quanto no producer.

@KafkaListener(topics = ["payment-topic"], containerFactory = "kafkaListenerContainerFactory")
fun consumePayment(
    @Payload transaction: TransactionItem,
    @Header(KafkaHeaders.OFFSET) offset: Long,
    @Header(KafkaHeaders.RECEIVED_PARTITION) partition: Int?,
    @Header(KafkaHeaders.RECEIVED_TOPIC) topic: String?,
    ack: Acknowledgment
) {
    try {
        log.info("Consume Kafka message - topic: {}, offset: {}, partition: {}", topic, offset, partition)
    } catch (
      ex: `Exception) {`
        log.error("Error processing message: {}", ex.message, ex)
    } finally {
        ack.acknowledge()
    }
}

Outro ponto importante é a segurança, em ambientes produtivos é essencial proteger o cluster Kafka. Isso pode incluir autenticação, autorização, SSL/TLS, entre outros. Aqui está um exemplo de configuração para habilitar SSL/TLS:

spring.kafka.properties.security.protocol: SSL
spring.kafka.properties.ssl.truststore.location: /path/to/truststore
spring.kafka.properties.ssl.truststore.password: truststorePassword
spring.kafka.properties.ssl.keystore.location: /path/to/keystore
spring.kafka.properties.ssl.keystore.password: keystorePassword

Essas configurações devem ser ajustadas de acordo com as necessidades específicas do ambiente e da política de segurança da organização.

Conclusão

Desde que comecei a aprender sobre mensageria e todas as possíveis aplicações percebi como é um tema vasto. Até focando apenas no Kafka já vemos como não é algo simples, sendo ele uma ferramenta robusta que pode ser utilizada para diversos cenários, desde streaming de dados até integração entre microsserviços. Neste artigo, vimos algumas das principais configurações que pode ser feitas em nossas aplicações, para ir mais além vá mais a fundo na documentação e realize testes dentro de casa.

A forma que mais aprendi sobre Kafka foi passando por problemas durante o desenvolvimento, e o que mais me auxiliou a resolver esses problemas foi entender melhor como a ferramenta funciona, por isso a introdução de conceitos básicos é essencial para quem está começando.

Espero que este artigo tenha sido último em sua jornada e que seja um ponto de partida para você começar a explorar cada vez mais o Kafka em seus projetos.

Fique a vontade para compartilhar tópicos que ache interessantes nos comentários!

Gostaria de agradecer ao Gustavo Santos Madeira por ter me apresentado estes conceitos sobre o Kafka me incentivado a ir mais a fundo nos estudos.

Caso tenha alguma crítica, sugestão ou dúvida fique a vontade para me enviar uma mensagem:

LinkedIn: https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Referências

• https://kafka.apache.org/
• org.springframework.kafka.listener (Spring for Apache Kafka 3.1.4 API)
• Avro Schema Serializer and Deserializer for Schema Registry | Confluent Documentation
• Kafka Schema Registry & Avro: Spring Boot Demo (2 of 2)
• Implementação de uma Fila e de um Tópico JMS

Você é um leitor ávido que adora consumir conteúdo do Medium? Já imaginou poder ler seus artigos favoritos no Kindle, com a tela maior e mais confortável?

Com o Article Kindle Converter, você pode fazer isso com apenas alguns cliques! Essa ferramenta gratuita converte artigos do Medium para o formato epub, permitindo que você os envie diretamente para o seu Kindle.

Como Funciona

1. Acesse o site: https://medium-kindle-sender.onrender.com
2. Cole o link do artigo: Insira o link do artigo do Medium que você deseja ler no Kindle.
3. Opcional: Adicione seu e-mail: Se desejar receber o artigo convertido por e-mail, digite seu endereço de e-mail.
4. Converta e baixe: Clique em “Baixar epub” para converter o artigo para o formato epub e baixá-lo para o seu computador.
5. Envie para o Kindle: Se você configurou o envio por e-mail, o artigo será enviado automaticamente para o seu Kindle. Caso contrário, você pode enviar o arquivo epub manualmente para o seu e-mail do Kindle.

Configuração do E-mail do Kindle

Para enviar artigos diretamente para o seu Kindle por e-mail, é necessário configurar o seu endereço de e-mail na Amazon (@kindle.com). Siga estas etapas que também estão descritas no site oficial Send to Kindle — E-mail (amazon.com.br):

1. Acesse Gerencie seu conteúdo e dispositivos
2. Vá para a guia “Preferências”.
3. Em “Configurações de Documentos Pessoais”, role para baixo até “Lista de E-mails de Documentos Pessoais Aprovados”.
4. Clique em “Adicionar um novo endereço de e-mail aprovado”.
5. Digite o endereço de e-mail que você deseja usar e clique em “Adicionar Endereço”.

Por enquanto esse é o único e-mail válido para usar com o Article Kindle Converter: automation@trial-3zxk54vne31ljy6v.mlsender.net

Recursos Adicionais

• Código Aberto: O código do Article Kindle Converter está disponível no GitHub: https://github.com/jjeanjacques10/medium-kindle-sender. Você pode contribuir com o projeto ou sugerir melhorias.
• Suporte: Se precisar de ajuda ou tiver alguma dúvida, consulte a página “Como Usar” no site da ferramenta: https://medium-kindle-sender.onrender.com/how-to-send-to-kindle

Conclusão

O Article Kindle Converter é uma ferramenta valiosa para quem gosta de ler artigos do Medium no Kindle. Com sua interface simples e intuitiva, você pode converter e enviar seus artigos favoritos para o seu dispositivo com facilidade.

Espero que goste e recomende para amigos!

Caso tenha alguma crítica, sugestão ou dúvida fique a vontade para me enviar uma mensagem:

LinkedIn: https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Podemos dizer que 90% dos problemas de uma empresa são causados pela falta de comunicação. Isso em nível de colegas de equipe e até entre áreas inteiras. Então, como podemos melhorar a forma como nos comunicamos e evitar dores de cabeça com problemas simples que acabam crescendo com o tempo? Neste artigo, proponho-me a trazer algumas dicas de como se expressar melhor, transmitir ideias de forma escrita e verbal.

Muito além das habilidades técnicas, um bom desenvolvedor precisa entender como compartilhar suas soluções e problemas com outras pessoas.

O poder de um bom texto….

Você já deve ter participado de uma reunião que poderia ter sido substituída por um e-mail… Frequentemente, ela ocorreu apenas porque acreditavam que seria “impossível” transmitir a ideia por escrito. Posso afirmar que a maioria delas realmente deveria ter sido um texto objetivo. No entanto, para alcançar esse patamar, é necessário compreender previamente como redigir textos de qualidade.

1. Cuidado com erros de digitação
2. Conheça seu público algo
3. Faça as perguntas certas

Cuidado com erros de digitação

O primeiro é o mais simples de todos: Evite equívocos de digitação ou de português, você não precisa redigir a redação do ENEM, nem ser formal constantemente. O dilema ocorre quando tais equívocos podem prejudicar a compreensão do leitor, portanto revise sempre que possível antes de clicar em “ENVIAR”. Alguns segundos adicionais não comprometerão sua oportunidade de compartilhar algo, mas substituir “significado” por “sinificado” pode gerar confusão para o leitor.

Conheça seu público

O segundo aspecto está intimamente relacionado à elaboração de palestras; um palestrante competente sempre pesquisa o público-alvo de seu conteúdo, a fim de aprimorar a forma como é apresentado. No texto, devemos ter a mesma preocupação; não é adequado chegar a uma reunião com profissionais de negócios discorrendo sobre conceitos altamente técnicos. Vejamos um exemplo:

A melhor forma de expressar isso seria abstraindo essas informações e focando no que é importante para esse público:

Faça as perguntas certas

O último ponto é importante independente da senioridade, ele se baseia no “saber perguntar”, um dos sites mais famosos para desenvolvedores é o stackoverflow, nele é crucial descrever de maneira precisa o problema a fim de buscar auxílio de programadores de todo o mundo. Essa prática também ocorre dentro das empresas, quando surge uma dúvida, é necessário enviar uma mensagem no Teams ou no Slack para alguém com maior experiência ou algum profissional de negócios.

Muitas vezes partimos do pressuposta que as outras pessoas tem o mesmo contexto que nós, que sabem todo o caminho que passamos para chegar até aquele ponto, mas nem sempre (grande parte das vezes) não é este o caso. Quando entrei na área, esse foi um dos melhores conselhos que recebi: “Mostre como você chegou a essa conclusão”. Segue mais um exemplo:

Costumo incluir também imagens, pois isso evita que a pessoa precise navegar por vários links para me auxiliar em algo simples. Caso seu colega possua alguma deficiência visual, adicione o texto, se possível, ou descreva o que anteriormente seria uma imagem. Quanto mais detalhes forem acrescentados, mais valor você está dando ao tempo de seus colegas de equipe.

Don’t ask to ask, just ask

Um site que encontrei por acaso e enfatiza bastante esse aspecto é o Don’t ask to ask, just ask. Ele concentra-se nas interações que ocorrem principalmente em fóruns da internet, onde alguém chega com a seguinte pergunta:

Como mencionado no tópico sobre formular as perguntas adequadas, é necessário sempre trazer o contexto do problema, preferencialmente descrevendo as medidas já tomadas para tentar solucioná-lo.

Ao adotar esse método, você obterá uma resposta mais rápida, pois a pessoa não precisará enviar uma nova mensagem perguntando sobre qual tipo de ajuda você precisa. Além de ajudar quem for pesquisar sobre este assunto futuramente, muitas vezes será você mesmo.

Aqui tem alguns exemplos do próprio stackoverflow de como escrever bons questionamentos (tradução livre feita por mim):

Bad: C# Problema de matemática
Good: Por que usar float em vez de int me dá resultados diferentes quando todas as minhas entradas são números inteiros?

Bad: [php] dúvida sobre sessões
Good: Como posso redirecionar usuários para páginas diferentes com base em dados de sessão em PHP?

Bad: problemas com if-else no Android
Good: Por que str == “valor” retorna falso quando str é definido como “valor”?

Iniciando uma conversa

Outra questão bastante comum é como iniciar uma conversa. Provavelmente, você já recebeu uma mensagem no chat com um simples “Oi, tudo bem?” que permaneceu ali até que você respondesse com um “Oi” de volta. No entanto, essa troca pode levar tempo, enquanto novas prioridades surgem e você não tem ideia da urgência daquela saudação sem contexto. Não devemos deixar as pessoas em “espera” como em uma ligação telefônica. Seja direto, fornecendo todas as informações necessárias de forma objetiva junto à saudação.

Não faça isso:

Prefira uma abordagem direta:

TechWriter

Em nossa área temos diversas vertentes, uma delas é a de TechWriters, que são profissionais especializados em escrever e comunicar informações técnicas de maneira clara e compreensível. Eles criam documentação, manuais de usuário e guias de instruções, ajudando a traduzir conceitos complexos em linguagem acessível. Embora os desenvolvedores não precisem ser TechWriters, é importante que aprendam com esses profissionais a compartilhar informações, garantindo o sucesso e a usabilidade de produtos e de software.

Se você tiver a oportunidade de trabalhar com estes profissionais peça algumas dicas, com certeza eles lhe ensinarão algo novo, assim como você ensinará a eles.

Inteligência artificial

Uma ótima ferramenta para lhe ajudar a escrever textos melhores é a Inteligência artificial (IA). Essa tecnologia tem se mostrado cada vez mais promissora na hora de revisar textos. Através de algoritmos avançados, as ferramentas de IA podem identificar erros gramaticais, sugerir correções e até mesmo oferecer alternativas de palavras e frases para melhorar a clareza e a fluidez do texto.

Algumas das opções mais utilizadas atualmente incluem o ChatGPT, Clarice.ai, copy.ai e várias outras.

Se você pretende utilizar essas ferramentas em ambientes corporativos, certifique-se de não violar nenhuma política interna relacionada ao compartilhamento de informações.

Timidez, uma barreira para se expressar

Aqui está outra vantagem de se expressar por texto. Sempre fui uma pessoa muito tímida e busquei por muito tempo não dar minha opinião em conversas no trabalho. Por isso, comecei a escrever. Na escrita, você se expõe menos e tem a chance de revisar mais de uma vez o que será enviado. Apenas tome cuidado para não ficar lapidando um texto até chegar na versão “perfeita”, porque ela não existe. É mais importante você ter uma versão direta com as informações mais importantes do que cobrir todos os cenários.

Além disso, a comunicação escrita também proporciona uma forma de registro e referência para futuras consultas. Ao expressar ideias por meio de textos, você cria um histórico que pode ser utilizado como base para tomadas de decisão, análises retrospectivas e aprendizados.

Algumas dicas extras

• Leia bastante, quem escreve bem é aquele que lê muito
• Pegue feedback com seus colegas de trabalho
• Não tenha medo de expor suas ideias

Conclusão

Escrevi esse artigo para compartilhar com vocês ações que me auxiliaram muito em minha carreira, ainda estou aprendendo a me expressar melhor a transmitir minha ideias para as pessoas, isso tudo é um processo que só vai melhorar com muita prática, assim como programar!

Pratique realizando anotações sobre a tarefa que está fazendo, se possível documente seu projeto, vai ajudar você e será uma forma fácil de compartilhar com novas pessoas que entrarem em sua equipe (sem passar horas em reuniões de overview).

Espero que tenha gostado e sempre que ver alguém fazendo uma pergunta sem muito contexto compartilhe esse artigo com essa pessoa! Vamos melhorar a forma que nos comunicamos e criar um mundo com menos desentendimentos!

Caso tenha alguma crítica, dúvida ou sugestão, fique à vontade para comentar abaixo ou nos envie uma mensagem:

Jean Jacques, Backend Software Engineer — https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Referências

• https://dontasktoask.com/
• https://nohello.net/en/
• http://catb.org/~esr/faqs/smart-questions.html
• https://stackoverflow.com/help/how-to-ask

Desde pequeno, ouço falar sobre Inteligência Artificial. Meu primeiro contato foi por meio dos filmes de ficção científica: “Eu, Robô” (2004) e “A.I. — Inteligência Artificial” (2001). Depois de vários anos, quando comecei a programar, o tema voltou à tona junto com Data Science e a “febre dos dados”, todos precisavam gerar dados para se manter no mercado e aproveitar os benefícios das IAs. Por volta de 2016, comecei a estudar mais a fundo e até considerei me tornar pesquisador nessa área. Hoje, sou apenas um entusiasta de IA e trabalho como desenvolvedor back-end Java.

Depois daquela primeira explosão em que todos falavam sobre Inteligência Artificial, o mercado meio que se acalmou. Agora, em 2023, estamos presenciando mais uma onda de pessoas se surpreendendo com a capacidade dos algoritmos que podem automatizar nossos trabalhos.

Não é de hoje esse alarde para a perda de empregos

Meu primeiro trabalho como programador foi criar uma página em WordPress para consumir uma API que retornava “As carreiras que vão desaparecer em 10 anos”, com base em uma pesquisa que dizia o seguinte:

“Até 2026, 30 milhões de vagas com carteira assinada poderão ser fechadas à medida que robôs avançam e ganham espaço. É o que aponta estudo realizado pelo Laboratório de Aprendizado de Máquina em Finanças e Organizações (LAMFO) da UnB (Universidade de Brasília), que avaliou 2,6 mil ocupações brasileiras utilizando denominações de cargos e funções do antigo Ministério do Trabalho e Emprego. A opinião especializada de 69 acadêmicos e profissionais atuantes em aprendizado de máquinas foi levantada para embasar o cálculo das probabilidades de automação.” — Robôs podem substituir 54% dos empregos formais do Brasil, prevê UNB — IT Forum

Essa não é a única pesquisa que traz alertas como esses, mas um ponto interessante sobre a maioria dessas pesquisas é que foram realizadas antes da pandemia. Esse evento mudou de várias formas a maneira como as pessoas interagem entre si, e também a forma que consomem produtos, gerando necessidades de mercado que se alteraram significativamente desde então.

Esse foi um ponto que levantei durante a leitura do livro “Inteligência artificial — Como os robôs estão mudando o mundo”, escrito por Kai-Fu Lee. Trata-se de uma obra excelente e que recomendo. O livro foi lançado em 2019, antes dos impactos da pandemia, e aborda algumas das mudanças que já estavam surgindo naquela época, incluindo pesquisas que alertavam sobre a perda em massa de empregos para sistemas automatizados. Minha perspectiva sobre o assunto é baseada nessa obra e em outras que li ao longo dos anos. Portanto, irei discorrer sobre os impactos atuais e avançarei para possíveis cenários futuros…

Ferramentas

Atualmente venho utilizando bastante os modelos generativos, como o GitHub Copilot e o ChatGPT, para me dar um apoio no dia a dia de trabalho. Venho percebendo um aumento na minha produtividade por conta destas ferramentas, assim como as linguagens de programação, que mostram para os programadores outra forma de fazer suas tarefas.

Tivemos diversas revoluções com o tempo… Cada geração de desenvolvedores teve o seu apoio:

Livros -> Fóruns na internet -> StackoverFlow -> Copilot

Apenas trocamos a página (ou aba, por assim dizer) de onde encontramos as repostas para nossas dúvidas. Não adianta correr disso!

Deixo aqui algumas sugestões de ferramentas que venho utilizando:

• GitHub Copilot: https://copilot.github.com/
• ChatGPT: https://chatbot.gpt.dobro.ai/
• Phind.ai: https://phind.ai/

Vamos perder nossos empregos?

Quanto à possibilidade do cargo de desenvolvedor de software desaparecer, eu adotaria uma abordagem mais realista: as IAs não eliminam “empregos”, mas sim funções específicas. E quais são as principais funções de um desenvolvedor?

• Análise de requisitos
• Alinhar expectativas com os clientes
• Design e arquitetura de software
• Codificação
• Documentação
• Trabalho em equipe
• Manutenção e suporte

Embora existam muitas outras funções, com base nas mencionadas acima, quais você acredita que um robô seria capaz de realizar? A resposta é: todas as tarefas repetitivas e tediosas, mas aquelas que envolvem empatia ainda estão longe de serem realizadas por IAs especialistas. Talvez nossos cargos mudem novamente (como já aconteceu várias vezes desde o surgimento do WebMaster haha) e tenhamos que aprender novas habilidades para nos mantermos no mercado de trabalho. No entanto, isso não deve ser assustador, especialmente para aqueles que trabalham com tecnologia, pois já deveriam estar acostumados com mudanças e disrupções.

Para quem está começando na área…

Se você está buscando entrar agora no mercado de trabalho como desenvolvedor, não há muita diferença em relação ao que estava acontecendo quando eu me candidatei para minha primeira vaga. Foque em resolver os problemas atuais com as ferramentas disponíveis, mas mantenha-se atualizado sobre as novidades que surgem e tente aplicá-las no seu cotidiano, isso sempre será visto como um diferencial e irá ajudar você a criar uma mentalidade flexível.

“Ser um(a) programador(a) vai além de escrever código; é ser capaz de trazer soluções inovadoras para os clientes, utilizando ferramentas e aplicando um pensamento sistêmico”

Perspectivas de futuro

Curto prazo

Existem dois tipos de IA: especialistas e generalistas. As especialistas são treinadas para realizar tarefas específicas, como reconhecimento de imagens e de voz. As generalistas têm a capacidade de desempenhar diversas tarefas, embora ainda não tenhamos uma IA de propósito geral que possa resolver todos os nossos problemas. Nesse sentido, é importante estudar os impactos que teremos na indústria, no mercado e no meio acadêmico, visando desenvolver um plano de ação bem estruturado. Esse processo requer o envolvimento de diversas áreas, como Filosofia, Sociologia, Psicologia e, claro, a própria Tecnologia.

Na minha visão, nos próximos anos veremos uma combinação do trabalho humano com o trabalho realizado pelas máquinas, o que já ocorre no meu dia a dia como desenvolvedor. Ambos irão se complementar. A Inteligência Artificial assumirá as tarefas pesadas, repetitivas e não criativas, enquanto os seres humanos se dedicarão ao trabalho criativo. Aqueles que não estão na área de tecnologia precisarão adotar a mesma mentalidade de adaptação, abandonando velhos hábitos para se manterem produtivos em um mundo onde essa habilidade será cada vez mais valorizada.

Daqui para frente, existem 2 cenários possíveis:

1. Vamos perder empregos para a automatização e o mundo vai entrar em colapso
2. Vamos perder empregos para a automatização e o mundo vai entrar em uma nova era de prosperidade

Longo Prazo

Para o longo prazo, prevejo muitas funções desaparecendo e a necessidade de profissionalização. Por exemplo, no caso do pacote Office: antes esse software ajudava nas tarefas que já eram realizadas, mas agora vamos precisar que as pessoas aprendam novas profissões e muitas delas ainda nem existem. Com o tempo, departamentos inteiros de empresas vão desaparecer, e precisaremos de uma coordenação entre os governos e as empresas privadas para entender como lidar com pessoas que não serão mais necessárias no mercado de trabalho. Não haverão tantos empregos como hoje, sendo que até no cenário atual faltam oportunidades de trabalho.

Atualmente, as empresas privadas, principalmente aquelas sediadas na China e nos Estados Unidos, são líderes na criação e posse dos modelos de IA, o que direciona os lucros para essas nações. Essa realidade gera uma preocupante desigualdade social, que já é evidente hoje, mas que tende a se agravar caso os governos e empresas não atuem de forma global para mitigar esse cenário. Esse é um dos pontos levantados por Kai-Fu Lee em seu livro, sobre como a substituição dos empregos irá atingir os profissionais com formação superior e teremos desemprego generalizado, mesmo com pessoas migrando de uma área para a outra, não haverá mercado o suficiente para tantos profissionais. A partir daí, precisaremos pensar em formas de distribuir essa renda que se contra em poucos países e empresas. Caso contrário, teremos um caos social.

Deixando claro que essas são perspectivas para um futuro distante, não acredito estar vivo para ver essa mudança drástica no modelo econômico mundial.

Conclusão

Como mencionei, esses modelos inteligentes têm me ajudado há algum tempo e vejo que estão se popularizando cada vez mais. Acredito que daqui para frente a área que mais precisaremos investir seja a educação, pois nenhuma geração vivenciou, em um curto espaço de tempo, a quantidade massiva de mudanças que está por vir. Precisamos aprender tanto quanto os modelos artificiais que estamos ensinando.

Estou animado para acompanhar os próximos passos que daremos em direção à uma sociedade que cresce junto com o desenvolvimento de novas tecnologias potencializadas pela Inteligência Artificial. Tenho, sim, minhas preocupações, principalmente em relação aos pontos que mencionei sobre desigualdade, mas acredito que podemos encontrar uma solução como sociedade para esses problemas!

Caso tenha alguma crítica, dúvida ou sugestão, fique à vontade para comentar abaixo ou nos envie uma mensagem:

Jean Jacques, Backend Software Engineer — https://www.linkedin.com/in/jjean-jacques10/

Gabriel Petillo, Product Owner — https://www.linkedin.com/in/gabrielpetillo/

Até a próxima!

Referências

• Inteligência artificial — Kai-Fu Lee
• Robôs podem substituir 54% dos empregos formais do Brasil, prevê UNB — IT Forum
• Introdução a inteligência artificial | by Jean Jacques Barros | Medium

Este é um guia que crie para auxiliar na criação de annotations customizadas no Spring Framework utilizando Kotlin

Trabalhando com Spring, uma das primeiras coisas que se nota é a quantidade de annotations que precisamos utilizar. Sendo que elas têm a finalidade de fornecer informações adicionais tanto para o compilador quanto para o Spring Framework, indicando como lidar com determinadas classes, métodos ou propriedades.

Como exemplo temos o @Service, @Controller, @Component e dentre várias outras comumente utilizadas. Mesmo com um grande número de anotações disponíveis por padrão pode ser interessante criar a sua própria, nesse artigo vou explicar um pouco sobre como criar e utilizar anotações em Kotlin.

Repositório projeto de exemplo:

Todos esses exemplos podem ser encontrados no seguinte repositório no GitHub: https://github.com/jjeanjacques10/annotations-kotlin-spring-boot

Pondo a mão na massa 👨🏻‍💻

Para isso vamos criar uma nova aplicação Spring Boot para realizar o cadastro de livros. Vamos começar adicionando o seguinte controller, observe que estou utilizando o @Valid, essa annotation é utilizada para validar os dados de entrada de uma requisição, sem ela as próximas configurações na classe BookRequest não funcionarão.

import javax.validation.Valid

@RestController
class BookController {
  @PostMapping("/book")
    fun create(@Valid @RequestBody book: BookRequest): Map<String, Any?> {
        return mapOf(
            "status" to 200,
            "details" to "Book created - ".plus(book.title)
        )
    }
}

Utilizando anotações de validação do Spring

Um dos usos mais comuns quando trabalhamos com API’s Rest é validar os dados de entrada enviados pelo usuário. Para isso podemos importar a lib javax.validation.constraints, nela temos várias anotações que podem ser utilizadas para validar os dados de entrada. A classe BookRequest representa os dados de entrada que serão enviados pelo usuário.

import javax.validation.constraints.NotBlank

data class BookRequest(
    @field:NotBlank
    val title: String? = ""
)

Nela temos o atributo title que possui acima dele o @NotBlank, essa annotation indica que o atributo não pode ser nulo e nem vazio. Temos diversas possibilidades quando utilizamos essa lib de validação, seguem as principais:

• @NotNull — Indica que o atributo não pode ser nulo
• @NotEmpty — Indica que o atributo não pode ser nulo ou vazio
• @NotBlank — Indica que o atributo não pode ser nulo ou vazio e não pode conter apenas espaços em branco
• @Size(min = 1, max = 10) — Indica que o atributo deve ter no mínimo 1 e no máximo 10 caracteres
• @Email — Indica que o atributo deve ser um email válido
• @Pattern(regexp = “^[a-zA-Z0–9]*$”) — Indica que o atributo deve seguir o padrão regex informado

❗ Importante: Passei um tempo quebrando a cabeça por não saber que no caso de validações em Kotlin precisamos utilizar o @field:<annotation> para que a anotação seja aplicada ao atributo

Por baixo dos panos 🕵🏼‍♂️

Vamos olhar um pouco mais fundo para entender como que essa flag com @ na frente funciona. Quando utilizamos uma annotation em Kotlin estamos utilizando uma feature chamada reflection, que basicamente permite que o código acesse informações sobre si mesmo em tempo de execução. Com isso podemos acessar informações sobre classes, métodos, atributos e etc.

Se entrarmos em uma das anotações do Spring, como por exemplo a @NoEmpty, podemos ver que ela é uma interface que herda de @Constraint, @Target e @Retention.

@Constraint(validatedBy = {})
@Target({ElementType.METHOD, ElementType.FIELD, ElementType.ANNOTATION_TYPE, ElementType.CONSTRUCTOR, ElementType.PARAMETER, ElementType.TYPE_USE})
@Retention(RetentionPolicy.RUNTIME)
public @interface NotEmpty {
    ...
}

Existem mais anotações que compõe NotEmpty, mas para fins didáticos não vou entrar em detalhes.

@Target especifica os tipos possíveis de elementos que podem ser anotados. Os valores possíveis são:

• CLASS: Pode ser aplicada em classes, interfaces e enums.
• FUNCTION: Pode ser aplicada em funções e construtores.
• PROPERTY: Pode ser aplicada em propriedades de classes.
• FIELD: Pode ser aplicada em campos de classes.

@Retention especifica se a annotation é armazenada nos arquivos de classe compilados e se ela é visível por meio de reflection em tempo de execução (por padrão, ambas são verdadeiras). Existem três possíveis valores para essa propriedade:

• SOURCE: É descartada pelo compilador e não está presente no bytecode gerado.
• CLASS: É mantida no bytecode, mas não está disponível em tempo de execução.
• RUNTIME: É mantida no bytecode e também está disponível em tempo de execução.

Esse é o básico de como funcionam as configurações das principais annotations no Spring. Vamos agora ver como podemos criar nossas próprias aplicando esses conceitos.

Criando uma annotation customizada

Mas não apenas do padrão vive o dev, às vezes nossos projetos pedem por comportamentos específicos que o framework não está apto a fornecer. Nesse caso podemos criar nossas próprias annotations, vamos então adicionar a validação se o gênero do livro é válidos.

Como comentado anteriormente, precisamos ter o @Target, que nesse caso será FIELD, pois queremos que apenas seja utilizada em atributos de classes. Também precisamos do @Retention, sendo ele definido como RUNTIME, já que esse tipo de validação é feita em tempo de execução. E por fim, a mais importante, a annotation @Constraint, nela que definimos a regra de validação que será utilizada.

import javax.validation.Constraint
import javax.validation.Payload
import kotlin.reflect.KClass

@MustBeDocumented
@Target(AnnotationTarget.FIELD)
@Retention(AnnotationRetention.RUNTIME)
@Constraint(validatedBy = [GenreValidator::class])
annotation class Genre(
    val message: String = "O gênero do livro é inválido",
    val groups: Array<KClass<*>> = [],
    val payload: Array<KClass<out Payload>> = []
)

Definimos na annotation @Genre três parâmetros: message, groups e payload. O primeiro é a mensagem de erro que será exibida caso a validação falhe, o segundo é um array de classes que podem ser utilizadas para agrupar validações e o terceiro também um array de classes que podem ser utilizadas para definir payloads customizados. Vamos preencher apenas a mensagem de erro, pois os outros parâmetros não serão utilizados nesse exemplo.

enum class GenreType {
    FANTASY,
    SCI_FI,
    ROMANCE,
    MYSTERY,
    HORROR,
    THRILLER,
    NON_FICTION
}

class GenreValidator : ConstraintValidator<Genre, String> {
    override fun isValid(value: String?, context: ConstraintValidatorContext?): Boolean {
        if (value == null) false
        return try {
            GenreType.valueOf(value!!)
            true
        } catch (e: IllegalArgumentException) {
            false
        }
    }
}

A lógica da constraint se encontra na classe GenreValidator, nela apenas verificamos se o valor do atributo está presente na lista de GenreType, caso não esteja ele retornará que esse valor é inválido. Agora vamos aplicar essa annotation na classe BookRequest.

data class BookRequest(
    @field:Genre
    val genre: String
)

Testando a annotation customizada

Agora com nossas annotations criadas vamos testar se elas estão funcionando corretamente. Quando realizamos uma chamada na API com um gênero inválido o retorno será 422 Unprocessable Entity.

Também podemos retornar uma lista com diversos erros, como por exemplo, quando o título do livro é nulo e o gênero é inválido:

Ao realizar a chamada na API com valores válidos o retorno será 200 OK, mostrando que o livro foi criado com sucesso.

Conclusão

Passei um bom tempo estudando sobre annotations no Spring para poder utilizar em um projeto, esse conteúdo é um resumo de tudo que pesquisei e consegui aplicar, espero que tenha lhe ajudado em sua jornada.

Caso tenha alguma crítica, sugestão ou dúvida fique a vontade para me enviar uma mensagem:

Linkedin: https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Referências

Doc Kotlin Annotations <https://kotlinlang.org/docs/annotations.html>

Kotlin Spring validation not working <https://youtrack.jetbrains.com/issue/KT-50511/Kotlin-Spring-validation-not-working>

Uma das grandes vantagens de utilizarmos a AWS ou qualquer outro provedor de Cloud é a possibilidade de pagar apenas pelos recursos que utilizamos. Uma ferramenta extremamente útil para gerenciar estes recursos de forma eficiente, evitando gastos desnecessários, é o Auto Scaling ou dimensionamento automático. Esta funcionalidade permite aumentar ou diminuir de forma dinâmica a quantidade desejada de tasks (máquinas rodando) em serviços como o Amazon Elastic Computer Service (ECS). Dessa forma, garantimos que a quantidade de tasks esteja adequada às necessidades da aplicação, optimizando custos e também mantendo nosso serviço disponível mesmo com o aumento de demanda.

O Amazon ECS oferece diversas vantagens na hora de configurar estratégias de escalonamento. Podemos personalizar essas configurações de acordo com o tipo de serviço, como por exemplo aplicações de e-commerce no período de Black Friday ou aquelas com poucos acessos durante a noite, cenários que envolvem uma carga de trabalho variável.

Hoje vou apresentar algumas estratégias que podem ser úteis em seus projetos visando o escalonamento horizontal, replicando as máquinas ao invés de aumentar o tamanho delas.

Lembrando que todos os códigos apresentados nesse artigo podem ser encontrados no seguinte repositório do GitHub: https://github.com/jjeanjacques10/springboot-ecs-fargate

Como funciona o Application Auto Scaling

O AWS Application Auto Scaling é um serviço que permite escalar automaticamente seus recursos Amazon EC2, Amazon ECS, Amazon EKS, Amazon DynamoDB e Amazon Aurora em resposta à demanda de aplicativos em constante mudança.

No exemplo acima temos o fluxo de Auto Scaling, para definir o recurso a ser dimensionado criamos um Scalable Target, que especifica a capacidade mínima e máxima desse recurso e também as políticas de dimensionamento dele, que determinam como o recurso aumenta ou diminui em resposta a mudanças na demanda. O serviço ECS (Digimon Service) está se comunicando o tempo inteiro com o CloudWatch e enviando métricas para os alarmes presentes nele que serão gerenciados pelo Application Auto Scaling e tem as regras definidas no Scaling Policy.

ScalableTarget:
  Type: AWS::ApplicationAutoScaling::ScalableTarget
  DependsOn: Service
  Properties:
    MinCapacity: 2
    MaxCapacity: 6
    ResourceId: !Join
      - "/"
      - - service
        - !Ref EcsClusterName
        - !GetAtt Service.Name
    RoleARN: !GetAtt AutoScalingRole.Arn
    ScalableDimension: ecs:service:DesiredCount
    ServiceNamespace: ecs

Agora para especificar como e quando escalar precisamos do Scaling Policy, vamos seguir então para alguns exemplos, começando pelo mais comum de encontrar em aplicações…

Uso de CPU ou Memória

Esse tipo de métrica utilizada no Scaling Policy é comum porque utiliza características de nossos serviços que dizem muito sobre o status atual da aplicação a nível de hardware. Nestes casos devemos definir um valor alvo a ser atingido (TargetValue) em qualquer uma das duas métricas, CPU ou memória RAM, e quando o valor é alcançado, como por exemplo 30% de uso da CPU, temos o aumento no número de tarefas rodando até o limite pré-estabelecido no Scalable Target. No caso do exemplo abaixo são no máximo 6 tasks e no mínimo 2 tasks.

ScalingPolicy:
  Type: AWS::ApplicationAutoScaling::ScalingPolicy
  Properties:
    PolicyName: ScaleWithCPUUtilization
    PolicyType: TargetTrackingScaling
    ScalingTargetId: !Ref ScalableTarget
    TargetTrackingScalingPolicyConfiguration:
      PredefinedMetricSpecification:
        PredefinedMetricType: ECSServiceAverageCPUUtilization
      TargetValue: 30.0

Para trocar para o verificar 30% do uso de memória alteramos o PredefinedMetricType para “ECSServiceAverageMemoryUtilization”.

Esse tipo de métrica pode ser utilizado para qualquer serviço, mas existem alguns cenários que outros tipos de alarmes podem ser mais interessantes. Por exemplo, podemos aumentar o número de tarefas observando serviços externos como filas SQS e utilizar a métrica de…

Quantidade de mensagens na fila

Quando trabalhamos com consumers a principal métrica utilizada é a quantidade de itens a serem processados, para isso podemos olhar para um SQS na AWS e de acordo com o aumento no número de mensagens antigas em uma fila disponibilizar mais tasks ou remover essa capacidade extra caso não tenha nada para ser processado.

Pondo a mão na massa vamos então vamos criar nossas Policies. Um ponto importante de saber é que podemos ter várias Policies, mas cada policy só pode ser dimensionada em uma única direção, por essa razão precisamos de duas neste caso.

ScalingPolicySQSUp:
  Type: AWS::ApplicationAutoScaling::ScalingPolicy
  Properties:
    PolicyName: ScaleWithSQSUp
    PolicyType: StepScaling
    ScalingTargetId: !Ref ScalableTarget
    StepScalingPolicyConfiguration:
      AdjustmentType: ChangeInCapacity
      Cooldown: 60
      MetricAggregationType: Average
      StepAdjustments:
        - MetricIntervalLowerBound: 0
           MetricIntervalUpperBound: 100
           ScalingAdjustment: 1
        - MetricIntervalLowerBound: 100
           ScalingAdjustment: 2

A primeira é referente ao UpScaling, nela será adicionado 1 contêiner quando a fila estiver entre 1000 e 1100, mas adicionará 2 quando houverem mais itens. Agora para diminuir o número de tasks quando cair a demanda criamos outra Policy com valores negativos, nesse caso quando estiver entre 900 e 999 itens será removida 1 task.

ScalingPolicySQSDown:
  Type: AWS::ApplicationAutoScaling::ScalingPolicy
  Properties:
    PolicyName: ScaleWithSQSDown
    PolicyType: StepScaling
    ScalingTargetId: !Ref ScalableTarget
    StepScalingPolicyConfiguration:
      AdjustmentType: ChangeInCapacity
      Cooldown: 300
      MetricAggregationType: Average
      StepAdjustments:
        - MetricIntervalUpperBound: 0
          ScalingAdjustment: -1

Criadas as ações vamos agora configurar os alarmes no CloudWatch do tipo ApproximateNumberOfMessagesVisible. Vamos precisa de dois alarmes o primeiro é para que quando a fila “digimon-queue” atingir 1000 mensagens, nesse momento a Action de “ScalingPolicySQSUp” será ativada para aumentar a capacidade. O segundo é para nos alertar de quando esse valor diminuir e assim sermos capazes de diminuir o número de tasks ativando a Action “ScalingPolicySQSDown”.

# Use SQS Queue to scale up
CloudWatchSQSAlarmScalingUp:
  Type: "AWS::CloudWatch::Alarm"
  Properties:
    AlarmName: "Alarm SQS Up"
    AlarmDescription: "Alarm if our SQS queue is higher than usual."
    Namespace: AWS/SQS
    EvaluationPeriods: 2
    Statistic: Average
    MetricName: ApproximateNumberOfMessagesVisible
    ComparisonOperator: GreaterThanThreshold
    Period: 60
    Dimensions:
      - Name: QueueName
        Value: digimon-queue
    Threshold: 1000
    AlarmActions:
      - !Ref ScalingPolicySQSUp

# Use SQS Queue to scale down
CloudWatchSQSAlarmScalingDown:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: "Alarm SQS Down"
      AlarmDescription: "Alarm if our SQS queue is smaller than usual."
      Namespace: AWS/SQS
      EvaluationPeriods: 1
      Statistic: Average
      MetricName: ApproximateNumberOfMessagesVisible
      Threshold: !Ref SqsMessagesVisibleThresholdScaleDown
      ComparisonOperator: LessThanOrEqualToThreshold
      Period: 60
      Dimensions:
        - Name: QueueName
          Value: digimon-queue
      Threshold: 1000
      AlarmActions:
      - !Ref ScalingPolicySQSDown

Quantidade de chamadas

Quando se trabalha com API’s uma ótima métrica para utilizar é a de quantidade de chamadas recebidas, principalmente nos cenários onde já temos a quantidade de transações por segundo (TPS) mapeada. A criação das Scaling Policies é muito parecido com o de itens na fila, a maior diferença é o Alarme no CloudWatch que será utilizado aqui.

ScalingPolicyTCPUp:
  Type: AWS::ApplicationAutoScaling::ScalingPolicy
  Properties:
    PolicyName: ScaleWithFlowCountTCPStepPolicyUp
    PolicyType: StepScaling
    ScalingTargetId: !Ref ScalableTarget
    StepScalingPolicyConfiguration:
      AdjustmentType: ChangeInCapacity
      Cooldown: 60
      MetricAggregationType: Average
      StepAdjustments:
        - MetricIntervalLowerBound: 0
          ScalingAdjustment: +1

ScalingPolicyTCPDown:
  Type: AWS::ApplicationAutoScaling::ScalingPolicy
  Properties:
    PolicyName: ScaleWithFlowCountTCPStepPolicyDown
    PolicyType: StepScaling
    ScalingTargetId: !Ref ScalableTarget
    StepScalingPolicyConfiguration:
      AdjustmentType: ChangeInCapacity
      Cooldown: 60
      MetricAggregationType: Average
      StepAdjustments:
        - MetricIntervalUpperBound: 0
          ScalingAdjustment: -1

Agora os alarmes que temos que criar são usados para monitorar as requisições recebidas e acionar um Grupo de Auto Scaling para aumentar ou diminuir com base no número de solicitações. O alarme compara o número de solicitações TCP nos últimos 60 segundos com o limite de 100 solicitações. Se o número de solicitações for maior que o limite, o alarme acionará ScalingPolicyTCPUp e caso seja menor acionará o ScalingPolicyTCPDown para dimensionar o Grupo de Auto Scaling de acordo com a regra pré-definida.

# Use Active flow count to scale up 
HighTpsAlarm:
  Type: AWS::CloudWatch::Alarm
  Properties:
    AlarmDescription: !Sub '${MicroServiceName} - High volume of requests'
    EvaluationPeriods: 1
    Threshold: 100
    ComparisonOperator: GreaterThanOrEqualToThreshold
    Period: 60
    Statistic: Sum
    MetricName: ActiveFlowCount
    Dimensions:
      - Name: LoadBalancer
        Value: !GetAtt LoadBalancer.LoadBalancerFullName
    Namespace: AWS/NetworkELB
    AlarmActions:
      - !Ref ScalingPolicyTCPUp

# Use Active flow count to scale down
LowTpsAlarm:
  Type: AWS::CloudWatch::Alarm
  Properties:
    AlarmDescription: !Sub '${MicroServiceName} - Low volume of requests'
    EvaluationPeriods: 1
    Threshold: 90
    ComparisonOperator: LessThanOrEqualToThreshold
    Period: 60
    Statistic: Sum
    MetricName: ActiveFlowCount
    Dimensions:
      - Name: LoadBalancer
        Value: !GetAtt LoadBalancer.LoadBalancerFullName
    Namespace: AWS/NetworkELB
    AlarmActions:
      - !Ref ScalingPolicyTCPDown

No momento em que o alarme é acionado, temos a ação sendo ativada, como demonstrado no exemplo abaixo, onde podemos observar o número de tarefas aumentando após diversas requisições.

Para verificar se essa configuração está certa podemos acessar nosso serviço ECS e entrar na aba “Auto Scaling”. Nela são apresenados detalhes da nossa configuração, como as regras de escalonamento e a política de subida e descida. Se a configuração estiver correta, esses parâmetros serão exibidos de acordo com as configurações feitas.

Horário (CRON)

Também é possível gerencia a quantidade de tarefas rodando por meio de Schedules que identificam o horário definido para aumentar ou diminuir o número de tasks.

Para definir qual horário nossa ação deve rodar podemos utilizar o CRON, que é um utilitário normalmente utilizado em linha de comando para agendar ações a serem realizadas no sistema.

Quando for configurar lembre-se que o tempo é em UTC, precisando então adicionar 3 horas (para quem está no Brasil)

Seguem um exemplo onde definimos que todo dia às 8h00 (11 UTC) iremos seguir uma regra de capacidade e a partir das 20h00 iremos parar todas as tarefas rodando.

ScalableTarget:
  <...>
  ScheduledActions:
    - ScalableTargetAction:
        MinCapacity: 0
        MaxCapacity: 0
      Schedule: 'cron(0 0 22 ? * MON-FRI)'
      ScheduledActionName: scale-down
    - ScalableTargetAction:
        MinCapacity: 2
        MaxCapacity: 6
      Schedule: 'cron(0 0 10 ? * MON-FRI)'
      ScheduledActionName: scale-up

Esta é uma excelente configuração para usar em ambientes de desenvolvimento ou teste, pois economiza recursos que normalmente não são usados em certos horários!

Com o Scaling Policy são diversas as possibilidades, aqui tem a documentação com todos os valores possíveis do campo PredefinedMetricSpecification. Lá temos alguns outros exemplos utilizando DynamoDB, conexões RDS, Storage Kafka e muito mais!

Conclusão

Apresentei as principais estratégias de como utilizar Auto Scaling e suas aplicações, o ponto mais importante é entender o melhor cenários para utilizar cada uma delas. Muitas vezes, acabamos não monitorando a métrica certa, o que acarreta problemas para os nossos aplicativos.

Espero que esse conteúdo o tenha ajudado à entender melhor como implementar Auto Scaling em aplicações ECS na AWS!

Caso tenha alguma crítica, sugestão ou dúvida fique à vontade para me enviar uma mensagem:

LinkedIn: https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Referências

• AWS::ApplicationAutoScaling::ScalableTarget ScalableTargetAction — AWS CloudFormation (amazon.com)
• Programar expressões usando rate ou cron — AWS Lambda (amazon.com)
• aws-cloudformation-user-guide/aws-properties-applicationautoscaling-scalabletarget-scheduledaction.md at main · awsdocs/aws-cloudformation-user-guide (github.com)
• Auto Scaling Microservices on ECS | by Idan Lupinsky | The Startup | Medium

Quando trabalhamos com grandes massas de dados diversas abordagens surgem na mente para realizar atualizações em lotes. Contudo, nem sempre essas soluções são práticas e dependem de configuração de uma infraestrutura e da criação de aplicações completas para um job que deveria ser simples de se fazer, como popular um campo ou removê-lo.

Uma das ferramentas que podemos utilizar nesses casos é o AWS Glue, que é uma plataforma serverless de ETL (Extract, Transform, Load), orientada a eventos fornecida pela Amazon. É um serviço de computação que executa código em resposta à eventos e gerência automaticamente os recursos de computação exigidos por esse código.

Todos os códigos apresentados nesse artigo podem ser encontrados no seguinte repositório do GitHub: https://github.com/jjeanjacques10/update-dynamodb-glue

Cenário

Como exemplo temos essa tabela no DynamoDB onde apenas as informações de número e nome de nossos Pokémon estão cadastradas. Surgiu uma nova regra de negócio e nosso cliente precisa que sejam retornadas as categorias de cada Pokémon, para que assim não seja necessário buscar em fontes externas. Vamos então realizar esse processo de atualização para ele!

Nesse exemplo temos 9 itens cadastrados (no total são 905 criaturinhas no mundo do anime), mas poderíamos ter terabytes de informação nesse tipo de base e realizar manualmente à atualização desses dados levaria muito tempo, sem falar que é necessário filtrar apenas os dados que precisam ser atualizados, assim evitando consumir recursos de forma desnecessária no DynamoDB, que é cobrado por capacidade de leitura e escrita.

Criando AWS Glue ETL Job

Adicionando as permissões

Para poder executar o script Glue é necessário ter uma Role com os acessos necessários, o primeiro é o Trusted Entity do tipo Service, onde iremos selecionar o serviço do Glue.

Com o arquivo de Role gerado sendo o seguinte:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "glue.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Como iremos trabalhar com o DynamoDB teremos que adicionar a Policy que libera o acesso à esse banco de dados e também ao S3 que é onde o nosso arquivo script.py será armazenado.

Você não precisa dar o FullAccess, a melhor prática é adicionar apenas as permissões necessárias, como por exemplo apenas leitura ou escrita.

Com a Role glue-pokemon-role criada e todas as permissões configuradas podemos ir para o desenvolvimento do script que vai fazer a mágica acontecer.

Script

Então vamos para a criação do nosso PySpark Script. O primeiro ponto é realizar o setup onde é criado o contexto e a sessão que iremos utilizar quando esse script for executado. Também temos aqui as importações que serão necessárias mais para frente.

import sys
import os
import requests
from awsglue.dynamicframe import DynamicFrame
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job

# @params: [JOB_NAME]
args = getResolvedOptions(sys.argv, ['JOB_NAME'])

sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)

Após iniciar o job é feita a conexão com o banco de dados. Nele informamos qual o nome da tabela e os parâmetros de configuração para essa conexão.

TABLE_NAME = "tb_pokemons"

dyf = glueContext.create_dynamic_frame.from_options(
    connection_type="dynamodb",
    connection_options={
        "dynamodb.input.tableName": TABLE_NAME,
        "dynamodb.throughput.read.percent": "1.0",
        "dynamodb.splits": "100"
    }
)

print(f"Count Items: {dyf.count()}")
print("Items:")
dyf.show()

Nas últimas linhas apresentamos a quantidade de itens listados e podemos dar um dyf.show() para mostrar todos os itens encontrados. Caso tenham muitas linhas em sua tabela é desejável que comente esse comando para evitar custos indesejáveis no CloudWatch 😅.

Vamos filtrar apenas os registros que nos interessam, fazemos isso por meio da função filter. Na Lambda a seguir digo que quero apenas os registros que não possuem “category”.

filtered_dyf = dyf.filter(f=lambda x: "category" not in x)

print(f"Count Items without category: {filtered_dyf.count()}")
print("Items without category:")
filtered_dyf.show()

Dados filtrados, já sabemos onde atacar, para popular esse campo iremos utilizar a PokeAPI, que é um serviço gratuito onde podemos buscar informações sobre todos os Pokémon deste vasto universo. Na função buscamos pelo número do registro e então atualizamos a linha com o valor encontrado.

def add_category(row):
    url = f"https://pokeapi.co/api/v2/pokemon/{row['number']}"

    row["category"] = requests.get(url).json()["types"][0]["type"]["name"]
    return row

# Filter out the rows that no have category
updated_dyf = filtered_dyf.map(add_category)

# Show date filtered
updated_dyf.show()

DataFrame atualizado agora é a hora de enviar esses dados para a tabela tb_pokemons utilizando o mesmo glueContext passamos como parâmetro o frame igual ao nosso DF.

if filtered_dyf.count() < 1:
    print('There are no items to process')
    os._exit(0)
else:
    print('There are items to process')

    # Update the table
    new_data = DynamicFrame.fromDF(updated_dyf.toDF(), glueContext, "new_data")

    write_df = glueContext.write_dynamic_frame_from_options(
        frame=new_data,
        connection_type="dynamodb",
        connection_options={
            "dynamodb.output.tableName": TABLE_NAME,
            "dynamodb.throughput.write.percent": "1.0"
        },
        transformation_ctx="write_df"
    )

    job.commit()

Resultado

Após rodar o script podemos verificar que os dados que faltavam de categoria agora estão inseridos na tabela!

Conclusão

A Amazon Web Services possuí diversos serviços que podem facilitar a nossa vida, normalmente o Glue é utilizado para trabalhos envolvendo Data Science ou engenharia de dados, trouxe para vocês um exemplo de como desenvolvedores podem utilizar essa ferramenta para resolver problemas do dia a dia.

Conseguimos realizar a atualizar em lote de forma fácil e rápida, sem precisar gerenciar uma arquitetura complexa como a criação de uma Lambda ou de uma aplicação apenas para isso. Essa prova de conceito serviu para mostrar o potencial de um script Python para evitar que utilizemos um canhão para matar uma formiga.

Caso tenha alguma crítica, sugestão ou dúvida fique à vontade para me enviar uma mensagem:

LinkedIn: https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Referências

• AWS Glue
  https://aws.amazon.com/glue/
• Connection types and options for ETL in AWS Glue
  https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-connect.html#aws-glue-programming-etl-connect-dynamodb
• Update DynamoDB Glue GitHub
  https://github.com/jjeanjacques10/update-dynamodb-glue
• PySpark Glue Tutorial
  https://github.com/johnny-chivers/pyspark-glue-tutorial
• How to export an Amazon DynamoDB table to Amazon S3 using AWS Step Functions and AWS Glue
  https://aws.amazon.com/blogs/big-data/how-to-export-an-amazon-dynamodb-table-to-amazon-s3-using-aws-step-functions-and-aws-glue/

Desde que conheci o conceito de Sigle-Table Design quis entender melhor como isso poderia ser aplicado em um cenário real, criei essa prova de conceito e gostaria de apresentar para vocês!

DynamoDB é um banco de dados No-SQL de chave-valor (key-value) criado pela AWS, ele tem como foco trabalhar com grandes volumes de dados oferecendo performance. Diversas empresas atualmente utilizam esse banco de dados, como por exemplo Itaú, Amazon, Mercado Livre e a própria AWS. Neste artigo irei abordar algumas diferenças que você teria ao utilizar a estratégia de Single-table.

O que é Single-table Design

Vamos começar lembrando um fato sobre o DynamoDB, sendo um banco de dados No-SQL, não tem o conceito de “joins”, portanto, se os dados estão na forma normalizada em várias tabelas, recuperar itens relacionados em mais de uma tabela exigirá várias solicitações em série para obter esses registros. No seguinte exemplo temos duas tabelas, a de personagens e a de revistas, que em nossa consulta retornam para o usuário informações sobre a os quadrinhos de um personagem específico e também seu perfil, aqui precisaríamos realizar duas consultas separadas para cada tabela.

Um método mais simples de obter esse mesmo resultado é centralizando tudo em apenas 1 tabela, aplicando o Single-Table Design, assim sempre que for necessário retornar informações do personagem e das revistas em que ele participa podemos realizar apenas 1 consulta que obteremos todos os dados.

Sendo essa a principal razão para migrar para uma single table no DynamoDB, a possibilidade de recuperar vários tipos de dados heterogêneos usando uma única solicitação.

Outra vantagem é que não será necessária a criação e acompanhamento de de alarmes ou métricas de monitoração para múltiplas tabelas, sendo que a cada uma que você provisiona novas configurações são necessárias, como permissões e monitoração como já citado. Quando centralizamos tudo em apenas uma tabela temos a redução de custos consumo para capacidades de leitura sendo que antes tínhamos o consumo dessa capacidade sendo feita em múltiplas queries e agora apenas 1 é necessária.

Modelando a tabela

Vamos iniciar nossa modelagem determinando quais entidades queremos trabalhar, esse processo é muito parecido com o que fazemos ou modelar tabelas em um banco relacional, como MySQL ou Oracle. No nosso caso de uso as duas entidades são Character (Personagem) e Comic (Quadrinho), como é possível observar na imagem a baixo poderíamos ter uma tabela para cada um deles.

Em banco relacionais temos a opção de realizar “JOIN’s” para obter a informação destas duas tabelas em conjunto, mas no DynamoDB isso não é possível.

Então vamos evoluir esse modelo aplicando o Single-Table Design a ele. Primeiro passo é definir os padrões de acesso que iremos utilizar:

• Retornar o perfil de um personagem
• Listar todos os perfis de personagens
• Listar todos os quadrinhos de um personagem
• Listar todos os quadrinhos

Nesta nova modelagem, já no estilo de nosso banco No-SQL, temos como PK (PartitionKey) a informação de Character juntamente com o seu nickname, e nossa SK (SortKey) é composta pelo tipo (PROFILE/COMIC) e seu identificador. Antes o que eram 2 tabelas se transformaram em apenas uma onde cada linha representa um tipo de dado, como o DynamoDB é um banco com esquema “fraco” podemos ter diferentes colunas em cada linha da tabela, por conta disso não ficamos presos em colunas desnecessárias, exemplo disso são as colunas “comicId” e “name”.

Agora, quando queremos buscar o Personagem e os Quadrinhos, podemos fazê-lo em uma única solicitação sem precisar de uma operação de concatenação.

Com esse conceito e com nossa tabela já modelada, vou mostrar agora como colocar a mão na massa e implementar chamadas em uma aplicação Spring Boot!

Criando nossa Aplicação Spring Boot

Criei a base do projeto utilizando o site: https://start.spring.io/ . Selecione as bibliotecas padrões do Spring Web para criação de uma API Rest.

Dependências

Após descompactar a pasta dele vamos iniciar adicionando as dependências necessárias, as duas libs que iremos utilizar são:

• AWS SDK
• DynamoDB Enhanced

<dependency>
    <groupId>software.amazon.awssdk</groupId>
    <artifactId>dynamodb-enhanced</artifactId>
    <version>2.17.263</version>
</dependency>
<dependency>
    <groupId>com.amazonaws</groupId>
    <artifactId>aws-java-sdk-dynamodb</artifactId>
    <version>1.11.857</version>
</dependency>

Obs: Não irei entrar em muitos detalhes sobre a configuração dessas duas libs, então caso tenha alguma dúvida pode entrar no repositório de exemplo na pasta config (comics/config/DynamoDbConfig.java)

Entidades

Nessa próxima etapa vamos criar nossa entidade que será a referência do item salvo em na tabela do Dynamo. Aqui temos a Entity de Characters apenas com os campos que esse tipo de dado necessita, na visão da tabela seria a linha com o SK PROFILE#.

Agora essa é referente ao item de Comics (Quadrinho), são muito parecidas, afinal apenas os campos “comicId” e “type” foram adicionados para esse tipo de objeto e que não existiam no outro. Na visão da tabela seria a linha com o SK COMIC#.

Agora para o cenário que comentamos anteriormente, onde são retornados ambos: profile e comics, vamos utilizar essa nova entidade que possuí todos os campos necessários para os dois itens. Nos casos onde um não é possível encontrar o campo no registro apenas será ignorado, como por exemplo profile que não te “comicId” e comic que não possuí “name”.

Pronto! Entidades criadas, elas serão a base para os próximos passos onde iremos realizar as consultas.

Realizando buscas

O DynamoDb trabalha com dois tipos de buscas o Scan e a Query, sendo o primeiro o mais lento e custoso, que faz uma pesquisa na tabela e retorna todas as informações, podemos até realizar filtros, porém, eles apenas serão aplicados depois de mapear todos os dados. O método Query é o mais recomendado a ser utilizado, onde apenas solicitamos a informação que precisamos. Contudo, o query apenas funciona em buscas utilizando os campos PartitionKey e SortKey que juntos forma o PrimaryKey. Este campo no DynamoDB pode ser simples ou composto.

• Simple Primary Keys: Consistem em uma PartitionKey e nenhuma SortKey.
• Composite Primary Keys: Consistem em uma PartitionKey e uma SortKey.

Para não ficarmos limitados apenas aqueles primeiros PK e SK que criamos podemos criar Global Secondary Indexes, que são PK’s e SK’s diferentes do que geramos na criação da tabela e correspondem a cópias de nossa tabela, facilitando assim na hora de realizar buscas. Por exemplo, seria a utilização do campo type (PK) e date (SK) para realizar filtros de tempo. Isso se mostra como uma vantagem, mas apenas podemos criar 20 desses indexes personalizados.

Para realizar buscas mais avançadas sem precisar de Global Secondary Indexes para tudo podemos utilizar o begins_with que faz um filtro em nossa SortKey, e essa é uma das principais vantagens de utilizar um Single-table Design. Aqui é um exemplo de código onde busco apenas o perfil de um personagem:

Também conseguimos filtrar todos os quadrinhos de um personagem específico utilizando o begins_with COMIC#.

Só é possível utilizar esse método begins_with em SortKeys.

Agora para o tipo de consulta que comentamos acima onde devolvemos essas duas consultas anteriores juntas, em apenas uma busca na tabela fazemos a query sem passar a informação de SortKey, apenas a nossa partition.

De forma simples evitamos consumir muitos recursos na hora de fazer o que antes seria um “JOIN” procurando a informação em duas tabelas. Exemplo de retorno:

[
    {
        "pk": "CHARACTER#greenlantern",
        "sk": "COMIC#58f59aa1",
        "type": "COMIC",
        "nickName": "greenlantern",
        "realName": null,
        "description": "Green Lantern: New Guardians is an American comic book series originally written by Tony Bedard with art by Tyler Kirkham and Batt and published by DC Comics. The team consists of representatives of each of the Corps that tap into a particular portion of the emotional spectrum.",
        "comicId": "58f59aa1",
        "title": "Green Lantern: New Guardians"
    },
    <.. Comics ..>
    {
        "pk": "CHARACTER#greenlantern",
        "sk": "PROFILE#greenlantern",
        "type": null,
        "nickName": "greenlantern",
        "realName": "Hal Jordan",
        "description": "Harold 'Hal' Jordan, one of the characters known as Green Lantern, is a superhero appearing in American comic books published by DC Comics.",
        "comicId": null,
        "title": null
    }
]

Repositório projeto de exemplo:

Todos esses exemplos podem ser encontrados no seguinte repositório no GitHub: jjeanjacques10/spring-dynamodb-single-table-design: Demo project for Spring Boot + DynamoDB Single Table Design (github.com)

Desvantagens

Em bases como essa temos algumas desvantagens, por exemplo a dificuldade para realizar análises de dados, como temos essas informações desnormalizadas, o processo de exportar esse tipo de tabela para ferramentas de analytic acaba se tornando complexo. Além disso, com o tempo surge a falta de flexibilidade para adicionar novos padrões de acesso, como por exemplo uma nova entidade que se relacionará com personagens e quadrinhos.

Outro ponto é a curva de aprendizado que acaba sendo maior para quem inicia em um projeto em andamento, sendo que no inicio como vimos foram necessárias diversas conversas para chegar em um modelo ideal, esse conhecimento teria que ser passado a frente juntamente com as regras de negócio que ajudaram a modelar esse resultado atual do projeto.

Conclusão

Com isso podemos concluir que o que irá determinar o uso desse tipo de design é o caso de uso que você tem em mãos. Como tudo em desenvolvimento de software esse tipo de abordagem é muito interessante, porém tem seus tradeoffs.

O uso de tabelas DynamoDB facilita muito no dia a dia, principalmente quando nossos dados são utilizamos muito para consultas, convido vocês a clonar o repositório com os exemplos, nele tem um ambiente criado para testes locais utilizando o Localstack, simulando o DynamoDB. Só colocando a mão na massas que será possível entender se essa abordagem cumpre com os desafios propostos!

Caso tenha alguma crítica, sugestão ou dúvida fique a vontade para me enviar uma mensagem:

Linkedin: https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Referências

The What, Why, and When of Single-Table Design with DynamoDB (alexdebrie.com)

Amazon DynamoDB single-table design using DynamoDBMapper and Spring Boot | AWS Database Blog

Getting started with DynamoDB and AWS SDKs — Amazon DynamoDB