@@joaovmlsilva3509 se conhece algum canal com essa qualidade fora do Br, comenta aqui que fiquei curioso. Não conheço muitos youtubers gringos apesar de entender o inglês
vou admitir q eu não curtia muito o canal do galego por focar muito no leetcode, agora q ele parece estar variando mais o conteudo eu to curtindo bem mais
Sobre o ponto por volta dos 8:40, o verbo utilizado, seja ele PUT ou POST, por si só não tem nada de idempotente. Isso se dá apenas pela lógica implementada do lado do servidor que processará estas requisições. Acho importante detalhar isso pq as vezes o novato pode achar que existe uma mágica no protocolo e que apenas mudando o verbo utilizado problemas de concorrência deste tipo seriam resolvidos. Poderíamos até ir mais a fundo neste tópico pois penso que esta discussão chega até a não fazer sentido, o conceito de idempotencia que se discute em volta de APIs restful, por exemplo no método PUT, muitas vezes refere-se ao fato de que a API deveria sobreescrever todos os campos de uma entidade com o payload recebido, daí podemos chegar à conclusão de que a mesma requisição feita múltiplas vezes em sequência/paralelo produzirá o mesmo efeito pois a entidade seria sobreescrita várias vezes mas com os mesmos valores. No ambito de um sistema onde a concorrência é o problema em questão, deveria existir algum tipo de mecanismo que evite o processamento de tais requisições iguais, e apenas mudarmos o verbo de uma requisição não é solução, o mecanismo que evitará este tipo de problema é implementado no sistema e não através do método utilizado. No mais, deixo meus parabéns pelo contéudo produzido, Augusto.
2:45 O Datomic (O "banco" de dados que a Nubank usa) tem uma função chama CAS (Compare and Swap) que é literalmente feita pra lidar com operações que tem risco de Double spending :)
17:00 só um cuidado aqui, essa regra de só arredondar no final pode não funcionar dependendo do tema da sua aplicação, caso seja um problema de Física, os erros devem ser arredondados antes de ser propagados, porque a casa de maior precisão é o que o seu equipamento mediu, por mais que em conversões você tenha mais casas decimais, isso não significa que sua medida fracionada seja precisa, pelo contrário, essas casas a mais devem ser descartadas. Ex: 10,5 cm (+- 0,1 cm) * 10,5 cm (+- 0,1 cm) = 110.2 cm. Não é 110.25 cm porque seu equipamento não tem precisão para os 0,05 cm, sendo necessário descartar (arredondar).
Fala Augusto, só para acrecentar um pouco, idepotencia é algo mais abrangente, e muitos desses bancos usa EDA, e ao usar PUT estamos limitando a idepotencia en outros cenarios especialmente quando precisamos propagar essa transação usando SAGAS, geralmente definimos algo que será nossa idempotency key que é como um request-id um UUID gerado pelo cliente mesmo, e algumas vezes podemos usar a logica como key, por exemplo: se o os dados é o mesmo (from, to, amount) em uma janela de 10 minutos então retorna sucesso sem duplicar a transação, perem geralmente uma request-id é o mais comum de se ver.
pois é pelo que eu entendo não é bem automagico, PUT é considerado indepodente porque normalmente você está explicitando o estado final de determinada propriedade do objeto no seu payload
Ia falar justamente isso. Vejo idepotencia sendo usada mais com POST junto com um idepotency id( um uuid) gerado do lado do cliente. Isso porque se a gnt usar somente a ideia do PUT gera varios problemas como: sera que o user nao queria fazer realmente uma transacao repetida? Como identificar se for chamado duas vezes pelo user ou por retry dos clientes? Dependendo do banco chamar duas vezes um update pode gerar um trigger que gera alguma acao como duas notificações para o user, etc
Em sistemas financeiro normalmente você inicia o processo de pagamento com um TCID, esse ID você inclusive envia para o banco central e ele deve ser sua chave de idempotencia
que vídeo top, Augusto! Gosto bastante dessa pegada em que vc lê o artigo e vai compartilhando seu ponto de vista e conhecimento com a gente. O que mais gosto é que vc, diferente de outros youtubers, não busca demonstrar que sabe tudo. Isso passa aquele sentimento de que estamos aprendendo juntos.
Sobre usar número inteiros ou decimais para representar centavos. Depende mt de cada situação. Vai ter situação que trabalhar com inteiros para representar centavos vai ser suficiente. Mas quando se trata de micro centavos, tipo a situação de rendimento diário de %0.3, cada linguagem de programação vai fornecer uma forma de trabalhar com numeros decimais com alta precisão. Por ex. PHP tem extensão decimal, e o javascript tem uma lib chamada decimal, elas conseguem trabalhar com casas decimais com alta precisão.
Sobre armazenar como inteiros, para mim é a melhor opção, você pode ter dois inteiros (um int64 pros dígitos após a vírgula, e um int8 pros dígitos antes da vírgula) ou pode simplesmente usar um int64 para guardar todos os centavos... No caso dos 0.3 seria somar os dígitos antes da vírgula + 3, sempre tenho a sensação de que decimal pode dar problema, mas não trabalho em Fintech então não sei, comentei isso logo no início, então posso estar errado sobre usar inteiro
Tenho um sistema que não é banco mas lida muito com preços, vendas, comissões. Nunca pensei em escrever tudo que eu aprendi entre erros e acertos ao tratar numeros decimais. O que eu faço hoje é bem próximo do que vi no video. Queria ter aprendido antes, teria evitado muitas dores de cabeça. Não uso float. Quanto menos conversoes e arredondamento melhor. Salvar logs de tudo.
Oi, Galego. O problema de usar decimal é que você pode acabar com float sem querer. Às vezes a ferramenta só tem float, por exemplo um Pandas da vida, outras vezes ela assume float por padrão, como quando você lê um arquivo CSV com inferência de tipo. Inteiro nunca vai te dar esse tipo de dor de cabeça, só precisa mesmo fazer a conversão antes de exibir. Bom feriado pra você, e um abraço pra Dona Janete.
Tem um exemplo muito bacana de quando o Uber teve que migrar o seu banco de dados de transações, e como eles fizeram isso. Tem vídeo na gringa explicando pra quem se interessar
03:20 Normalmente não existe processos que atualize(update) valores... apenas Insert. as 10:12 tu viu os dados imutáveis. Id Potente 13:42 Acho que a tradução do texto está errado.. ele deve ser referir a número flutuante(float, money) 14:12 Para evitar erro de arredondamento. 17:12 Vem o cliente reclamar no banco central que o banco ficou com 1 centavos dele...
Uma coisa que aprendi usando Stripe é armanezar tudo em inteiro e na hora de mostrar fazer a conversão (dividindo por 100). Facilita demais o armazenamento e manipulação dos dados.
Mas como ele falou, depende do contexto. A explicação dele sobre os inteiros não foi tão boa, mas se você for testar fazer um acréscimo de porcentagem no valor inteiro pode dar errado. No caso que eu tenha 5 reais, que é 500 centavos, se em um dia o rendimento for de 0.03%, vai dar problema, pois 500 * 0.0003 = 0.015 centavos. Como irá colocar isso nos centavos? Aí vai depender do que você irá enfrentar E alguém tiver solução para isso, eu ficar bastante grato, pq eu mesmo não sei como resolver kkkkkkkkk
@@nikollasdavid7082 é só usar a casa decimal de referência pra armazenar os inteiros. Exemplo: você quer armazenar até a quinta casa decimal: 100.12345 Então o número vai ser 100123456. 15 centavos então seria 15000 em inteiro
1:10 Você NÃO armazena um inteiro dos reais e outro do decimal... você armazena um único inteiro com o grau de precisão que você quer ter, por exemplo, se você quer ter uma precisão de 5 dígitos após a vírgula você conta quantos "milésimos de centavos" você tem (1.000.000 no caso de 10 reais). No Decimal você também precisa estimar a precisão do número, então esse problema que você coloca do rendimento diário baixo é o mesmo problema em ambas as abordagens... se você não usa a precisão que você precisa você perde informação relevante. Inteiros são melhores que "Decimal" porque: 1 - Tem no fim a mesma precisão e em ambas abordagens você consegue controlar o grau de precisão (quantidade de dígitos) 2 - Inteiros BigINT tem precisão pro lado "esquerdo" infinita. 3 - Inteiros são estruturas mais simples, com performance bem melhor do que Decimais. 4 - Decimais ocupam muito mais espaço e memória do que inteiros 5 - Nem todos os sistemas e linguagens suportam Decimais, acontecendo deles serem convertidos em INT E só para complementar, para quem não sabe, Decimal é diferente de float e double e a razão porque ninguém usa float e double é porque eles não tem precisão.
Perfeito.. Na hora que ele falou eu fiquei pensando "uai..." Por exemplo, o próprio protocolo do Bitcoin usa o mecanismo com inteiros para as unidades em Satoshis etc
Gostei bastante desse formato de video e da forma que esse artigo evidenciou cenarios que não são comuns no meu dia a dia. Alguem ja leu algum um artigo parecido mas em sistemas em um contexto de ecommerce?
Trabalho em TI de banco. Adorei o artigo. Sobre casas decimais e precisão, a Taxa Referencial emitida pelo BACEN todo mês tem um formato como “0,000000123” (a grosso modo). Pode ser inteiro? Isso cria uma complexidade para representar esse tipo de valor onde você precisa criar marcações (com uso do 123E-X) . Eu ainda fico com Decimal e String (tráfego somente).
pra grande maioria dos casos que passei armazenar como centavos foi uma ótima solução, quando não fiz me arrependi mais tarde. mas não tive nenhum caso com rendimento como mostrou mesmo
Um truque para ledgers: ter uma coluna last_balance atrelado ao registro da carteira. Nem sempre reprocessar um dataset é viável e ter esse número na mão torna alguns números muito mais próximos e baratos.
15:06 Eu fiquei o video inteiro pensando "pô mano mas é obvio que a melhor abordagem é multiplicar o valor por 1000 em toda operação e dividir por 1000 no final da operação". Tipo, não seria 0.03% de 10.00, seria (0.03% de (10*1000))/1000. Satisfatório ver meus pensamentos serem concretizados nesse trecho no vídeo.
sobre a conversão, você só converte no dia que fechar o câmbio. Se o banco fecha todo dia, ele converte todo dia, se você é uma empresa de comercial importadora / exportadora, normalmente você faz isso 1x por semana. Você só converte nesse momento, porque é quando você tem o valor do dólar fixado.
uns meses atrás eu tentei pagar meu cartao com saldo na conta (que era o valor exato da fatura) no nubank ele me avisava que eu nao tinha saldo, precisei fazer um pix de 1 centavo de outra conta e consegui pagar a fatura, nao acredito que fintech ainda comete esse erro basico com float...
Vale ressaltar que a escolha do verbo HTTP não dá garantia nenhuma… se a operação não for implementada de forma a garantir idempotência, a escolha de um outro verbo é uma mudança puramente estética. Fazer menção a transações ACID faz muito mais sentido nesse caso.
Ola jovem!! Muito bom o video!! Traz luz a muitos aspectos que normalmente a gente so aprende errando!! Um ponto que eu acho que nao foi tratado no artigo é a questão de operacoes com ponto flutuante! Muitas linguagens (como Java) tem erros grotescos como por exempo: 0.1 + 0.2 = 0.30000000000000004 !!! Isso parece pouco, mas pode causar diversos problemas, principamente ao longo de milhares de operacoes. Por isso alguns sistemas precisam tratar valores com classes especificas (como o BigDecimal), ou mesmo criar solucoes como armazenar a um numero decimal como sendo 2 numeros inteiros (o numero antes da virgula e o numero depois da virgula), mas os operadores destes numeros compostos sao bastante complicadas de implementar. Neste caso linguagens como o COBOL brilham quando comparada ao Java. A questao do POST vs PUT pode ser resolvida incluindo-se o "ID" em ambas, onde o backend usa este id para identificar unicamente a transacao (entidade). Enfim... muitas destas coisas a gente so consegue perceber depois de ter passado pelo problema!! Seria muito bom se as pessoas soubessem aprender com os erros dos seus predecessores.
@@gssj-o8p Justamente. Esse erro acontece porque o processador não tem a capacidade de representar todos os números reais entre os valores máximo e mínimo que um float ou um double representa.
@@Gustavotrestento1 É verdade! Mas eu citei o Java pq isso corre no tipo double dele! Ja em outras linguagens como Cobol e Pascal, este tipo de problema nao ocorre (pode ser que a linguagem ja trate internamente)... da mesma forma que com BigDecimal do java isso tb nao ocorre! Enfim... sao estes tipos de problemas que a propria linguagem ja deveria tratar!!
Em COBOL, a representação padrão é decimal. Com a usage DISPLAY, cada dígito fica armazenado em um byte. Como isso é bastante custoso, é mais comum a usage COMP-3 (PACKED-DECIMAL), que armazena valores decimais na representação BCD, com dois dígitos por byte. Mas ambas opções contornam o problema de arredondamento do ponto flutuante :)
Eu tive que implementar recentemente uma interface na aplicação para trabalhar com 5 gateways financeiros. Eu tive que traduzir a regra de negócio da aplicação para cada gateway. Um trabalhava com int, outro com float, outro decimal... foi uma loucura, principalmente na parte de calcular comissões.
Não se usa ponto flutuante para valores financeiros, se usa inteiros ; se precisar de maior precisão , é só definir um fator de precisão. Simplifica absolutamente tudo: cálculo em plataformas diferentes (postgres, redis, etc) e resolve problemas de símbolos e formatações em integrações.
A explicação dele sobre os inteiros não foi tão boa, mas se você for testar fazer um acréscimo de porcentagem no valor inteiro pode dar errado. No caso que eu tenha 5 reais, que é 500 centavos, se em um dia o rendimento for de 0.03%, vai dar problema, pois 500 * 0.0003 = 0.015 centavos. Como irá colocar isso nos centavos? Aí vai depender do que você irá enfrentar E alguém tiver solução para isso, eu ficar bastante grato, pq eu mesmo não sei como resolver kkkkkkkkk
@@nikollasdavid7082 "imagine que para armazenar um valor de dinheiro na base de dados, convertemos para centavos, e ainda multiplicamos para um fator de precisão de 1000. Então, R$ 5,00, seria representado como 5*100*1000 = 500000. Como incrementariamos 0,03% a esse valor ?" Coloca isso no chatgpt, ele vai te explicar. Trabalhei em um sistema de APIs que cobrava por requests, e os valores eram incrivelmente baixos, tipo R$ 0,000000123. Tinhamos problemas de integração, e problemas de diferença de precisão em calculos - o postgres dava um resultado, no redis dava outro. No final das contas, percentual por ser representada como uma multiplicação. E processadores trabalham muito melhor com inteiros, ponto flutuante é problema gratuíto. Anteriormente também trabalhei em uma operadora de cart]ao de crédito, ele usavam somente centavos em tudo. O PagSeguro também está usando centavos na API deles agora (usavam "moeda" anteriormente). Representar moeda em forma de inteiro é infinitamente melhor que ponto flutuante.
@@nikollasdavid7082 "imagine que para armazenar um valor de dinheiro na base de dados, convertemos para centavos, e ainda multiplicamos para um fator de precisão de 1000. Então, R$ 5,00, seria representado como 5*100*1000 = 500000. Como incrementariamos 0,03% a esse valor ?" Coloca isso no chatgpt, ele vai te explicar. Trabalhei em um sistema de APIs que cobrava por requests, e os valores eram incrivelmente baixos, tipo R$ 0,000000123. Tinhamos problemas de integração, e problemas de diferença de precisão em calculos - o postgres dava um resultado, no redis dava outro. No final das contas, percentual por ser representada como uma multiplicação. E processadores trabalham muito melhor com inteiros, ponto flutuante é problema gratuíto. Anteriormente também trabalhei em uma operadora de cartões de crédito, ele usavam somente centavos em tudo. O PagSeguro também está usando centavos na API deles agora. Representar moeda em forma de inteiro é infinitamente melhor que ponto flutuante.
@@nikollasdavid7082 Eu uso 4 ou 6 unidades decimais pra garantir que multiplicações e divisões não vão dar problema. Daí é só usar banker's rounding na hora de exibir na tela
Acha que controlar timezone ja da problema hoje, imagina quando começar exploração espacial e tivermos que considerar o time de outros planetas rsrsrsrs
Até onde eu saiba, decimal é inteiro. As operações aritméticas com decimal não usam ponto flutuante, o que garante uma precisão maior. Não sei se já tem vídeo no canal, mas seria interessante falar sobre representação de dados no computador. O que um inteiro? O que é um float? Como o computador soma floats?
na verdade, eyu sempre usei inteiros porem, uso tabelas auxiliares justamente para evitar isso da aplicação de render 0,003 ou mesmo sei la um serviço ao mês custa 30 reais, mas tenho que calcular por hora/uso... até porque, inteiro tu tem precisão, doubles/ decimal tu perde precisão, mas pra alguns casos financeiro, tabelas auxiliares e seguindo o padrão lá acho que é da abnt ou é outro orgão que eu não lembro o nome, tu padroniza, nem que faça checagem de valores enfim..
Se modelar uma aplicação com juros diários, não iria armazenar no banco o valor presente de cada dia, vc armazena o principal, a data do investimento e a taxa de juros e calcula o valor presente em runtime.
Na verdade, quando se taxas e rendimentos sobre o montante, não é uma boa prática somar diretamente no montante. Isso causa erros de arrendamento e , somados esses erros, Causa uma imprecisão gigantesca com valores muito altos ou uma cardinalidade grande de números pequenos. disso não tem como escapar. Invés disso, vc marca os dias que tal taxa atuou, a data que vai agregar e soma apenas no final ao apresentar o resultado
Tem o problema dos rendimentos, multiplicar por uma porcentagem, ex: 300 reais, rendeu 1,08% vira R$ 303,24 inteiro perderia a fração. Precisaria usar dois inteiros, um para a "parte fracionária" (com vários zeros à direita para ter precisão) e outro para a "parte cheia" do valor? Teria que usar algo da linguagem, BigDecimal, Decimal inicializando com string pra não ter confusão.
vc é o unico da bolha dev que produz conteudo bom desse tipo
Verdade, ele me lembra o Filipe Deschamps com conteúdos técnicos sem enrolação!
Da bolha dev br*
@@joaovmlsilva3509 se conhece algum canal com essa qualidade fora do Br, comenta aqui que fiquei curioso. Não conheço muitos youtubers gringos apesar de entender o inglês
bolha dev br virou canal de fofoca, lucas montano, mano deyvin, etc.
vou admitir q eu não curtia muito o canal do galego por focar muito no leetcode, agora q ele parece estar variando mais o conteudo eu to curtindo bem mais
Sobre o ponto por volta dos 8:40, o verbo utilizado, seja ele PUT ou POST, por si só não tem nada de idempotente. Isso se dá apenas pela lógica implementada do lado do servidor que processará estas requisições. Acho importante detalhar isso pq as vezes o novato pode achar que existe uma mágica no protocolo e que apenas mudando o verbo utilizado problemas de concorrência deste tipo seriam resolvidos.
Poderíamos até ir mais a fundo neste tópico pois penso que esta discussão chega até a não fazer sentido, o conceito de idempotencia que se discute em volta de APIs restful, por exemplo no método PUT, muitas vezes refere-se ao fato de que a API deveria sobreescrever todos os campos de uma entidade com o payload recebido, daí podemos chegar à conclusão de que a mesma requisição feita múltiplas vezes em sequência/paralelo produzirá o mesmo efeito pois a entidade seria sobreescrita várias vezes mas com os mesmos valores. No ambito de um sistema onde a concorrência é o problema em questão, deveria existir algum tipo de mecanismo que evite o processamento de tais requisições iguais, e apenas mudarmos o verbo de uma requisição não é solução, o mecanismo que evitará este tipo de problema é implementado no sistema e não através do método utilizado.
No mais, deixo meus parabéns pelo contéudo produzido, Augusto.
Tem muito canal de Dev bom mas sempre clico quando vejo esse, conteúdo de forma mais técnica assim é bom demais
2:45 O Datomic (O "banco" de dados que a Nubank usa) tem uma função chama CAS (Compare and Swap) que é literalmente feita pra lidar com operações que tem risco de Double spending :)
17:00 só um cuidado aqui, essa regra de só arredondar no final pode não funcionar dependendo do tema da sua aplicação, caso seja um problema de Física, os erros devem ser arredondados antes de ser propagados, porque a casa de maior precisão é o que o seu equipamento mediu, por mais que em conversões você tenha mais casas decimais, isso não significa que sua medida fracionada seja precisa, pelo contrário, essas casas a mais devem ser descartadas.
Ex:
10,5 cm (+- 0,1 cm) * 10,5 cm (+- 0,1 cm) = 110.2 cm. Não é 110.25 cm porque seu equipamento não tem precisão para os 0,05 cm, sendo necessário descartar (arredondar).
Fala Augusto, só para acrecentar um pouco, idepotencia é algo mais abrangente, e muitos desses bancos usa EDA, e ao usar PUT estamos limitando a idepotencia en outros cenarios especialmente quando precisamos propagar essa transação usando SAGAS, geralmente definimos algo que será nossa idempotency key que é como um request-id um UUID gerado pelo cliente mesmo, e algumas vezes podemos usar a logica como key, por exemplo: se o os dados é o mesmo (from, to, amount) em uma janela de 10 minutos então retorna sucesso sem duplicar a transação, perem geralmente uma request-id é o mais comum de se ver.
pois é pelo que eu entendo não é bem automagico, PUT é considerado indepodente porque normalmente você está explicitando o estado final de determinada propriedade do objeto no seu payload
Ia falar justamente isso. Vejo idepotencia sendo usada mais com POST junto com um idepotency id( um uuid) gerado do lado do cliente.
Isso porque se a gnt usar somente a ideia do PUT gera varios problemas como: sera que o user nao queria fazer realmente uma transacao repetida? Como identificar se for chamado duas vezes pelo user ou por retry dos clientes? Dependendo do banco chamar duas vezes um update pode gerar um trigger que gera alguma acao como duas notificações para o user, etc
Em sistemas financeiro normalmente você inicia o processo de pagamento com um TCID, esse ID você inclusive envia para o banco central e ele deve ser sua chave de idempotencia
Todo vídeo seu é uma aula!
Trás mais vídeos assim, relacionado a regras de negocio que implicam na programação.
que vídeo top, Augusto! Gosto bastante dessa pegada em que vc lê o artigo e vai compartilhando seu ponto de vista e conhecimento com a gente.
O que mais gosto é que vc, diferente de outros youtubers, não busca demonstrar que sabe tudo. Isso passa aquele sentimento de que estamos aprendendo juntos.
Eu coloco meu BigDecimal em modo de defesa no campo de batalha. Assim termino minha rodada!
Nesse caso eu iria com a nova api Money do Java.
Eu jogo meu vint e encerro minha rodada. 😂
Invoco o Infinity do JS e quebro todo sistema financeiro
Sobre usar número inteiros ou decimais para representar centavos. Depende mt de cada situação. Vai ter situação que trabalhar com inteiros para representar centavos vai ser suficiente. Mas quando se trata de micro centavos, tipo a situação de rendimento diário de %0.3, cada linguagem de programação vai fornecer uma forma de trabalhar com numeros decimais com alta precisão. Por ex. PHP tem extensão decimal, e o javascript tem uma lib chamada decimal, elas conseguem trabalhar com casas decimais com alta precisão.
@@eduardornh termina no arredondamento, ai pode-se usar o arredondamento padrão ou a norma abnt (que tem algumas peculiaridades)
Sobre armazenar como inteiros, para mim é a melhor opção, você pode ter dois inteiros (um int64 pros dígitos após a vírgula, e um int8 pros dígitos antes da vírgula) ou pode simplesmente usar um int64 para guardar todos os centavos... No caso dos 0.3 seria somar os dígitos antes da vírgula + 3, sempre tenho a sensação de que decimal pode dar problema, mas não trabalho em Fintech então não sei, comentei isso logo no início, então posso estar errado sobre usar inteiro
Tenho um sistema que não é banco mas lida muito com preços, vendas, comissões.
Nunca pensei em escrever tudo que eu aprendi entre erros e acertos ao tratar numeros decimais. O que eu faço hoje é bem próximo do que vi no video. Queria ter aprendido antes, teria evitado muitas dores de cabeça.
Não uso float.
Quanto menos conversoes e arredondamento melhor.
Salvar logs de tudo.
Oi, Galego. O problema de usar decimal é que você pode acabar com float sem querer. Às vezes a ferramenta só tem float, por exemplo um Pandas da vida, outras vezes ela assume float por padrão, como quando você lê um arquivo CSV com inferência de tipo. Inteiro nunca vai te dar esse tipo de dor de cabeça, só precisa mesmo fazer a conversão antes de exibir. Bom feriado pra você, e um abraço pra Dona Janete.
Boa noite, Augusto! Seria legal que voce compartilhasse conosco os blogs que você lê diariamente.
Tem um exemplo muito bacana de quando o Uber teve que migrar o seu banco de dados de transações, e como eles fizeram isso. Tem vídeo na gringa explicando pra quem se interessar
Cara, nem assisti o vídeo ainda, mas eu estava buscando por isso há um tempo atrás, muito thanks
Mano, to acompanhando vc já tem um tempo e teu conteúdo é top demais!
complemento, artigo da conjur: Descartar milésimos da moeda em cálculo de ICMS caracteriza sonegação fiscal (matemática tributária)
Geralmente arredonda pra cima
1º beijo vó! depoois que vídeo braboooooo! obrigado Galego
03:20 Normalmente não existe processos que atualize(update) valores... apenas Insert.
as 10:12 tu viu os dados imutáveis. Id Potente
13:42 Acho que a tradução do texto está errado.. ele deve ser referir a número flutuante(float, money)
14:12 Para evitar erro de arredondamento.
17:12 Vem o cliente reclamar no banco central que o banco ficou com 1 centavos dele...
Uma coisa que aprendi usando Stripe é armanezar tudo em inteiro e na hora de mostrar fazer a conversão (dividindo por 100). Facilita demais o armazenamento e manipulação dos dados.
Mas como ele falou, depende do contexto.
A explicação dele sobre os inteiros não foi tão boa, mas se você for testar fazer um acréscimo de porcentagem no valor inteiro pode dar errado. No caso que eu tenha 5 reais, que é 500 centavos, se em um dia o rendimento for de 0.03%, vai dar problema, pois 500 * 0.0003 = 0.015 centavos. Como irá colocar isso nos centavos? Aí vai depender do que você irá enfrentar
E alguém tiver solução para isso, eu ficar bastante grato, pq eu mesmo não sei como resolver kkkkkkkkk
Muito melhor. Toda base de código boa da área financeira que trabalhei usa a mesma estatégia, ponto flutuante é complexidade gratuíta.
A maioria das fintechs que trabalhei tbm faz assim
@@nikollasdavid7082 é só usar a casa decimal de referência pra armazenar os inteiros.
Exemplo: você quer armazenar até a quinta casa decimal:
100.12345
Então o número vai ser 100123456.
15 centavos então seria 15000 em inteiro
@@nikollasdavid7082 Seria R$5,00 com rendimento de 0,03%. (500 * 0.03) / 100 = 0.15 | 0.15 * 100 = 15 | Ficaria 515. seria isso?
1:10 Você NÃO armazena um inteiro dos reais e outro do decimal... você armazena um único inteiro com o grau de precisão que você quer ter, por exemplo, se você quer ter uma precisão de 5 dígitos após a vírgula você conta quantos "milésimos de centavos" você tem (1.000.000 no caso de 10 reais). No Decimal você também precisa estimar a precisão do número, então esse problema que você coloca do rendimento diário baixo é o mesmo problema em ambas as abordagens... se você não usa a precisão que você precisa você perde informação relevante.
Inteiros são melhores que "Decimal" porque:
1 - Tem no fim a mesma precisão e em ambas abordagens você consegue controlar o grau de precisão (quantidade de dígitos)
2 - Inteiros BigINT tem precisão pro lado "esquerdo" infinita.
3 - Inteiros são estruturas mais simples, com performance bem melhor do que Decimais.
4 - Decimais ocupam muito mais espaço e memória do que inteiros
5 - Nem todos os sistemas e linguagens suportam Decimais, acontecendo deles serem convertidos em INT
E só para complementar, para quem não sabe, Decimal é diferente de float e double e a razão porque ninguém usa float e double é porque eles não tem precisão.
Fechado com você meu caro
Perfeito..
Na hora que ele falou eu fiquei pensando "uai..."
Por exemplo, o próprio protocolo do Bitcoin usa o mecanismo com inteiros para as unidades em Satoshis etc
Gostei bastante desse formato de video e da forma que esse artigo evidenciou cenarios que não são comuns no meu dia a dia. Alguem ja leu algum um artigo parecido mas em sistemas em um contexto de ecommerce?
Meu deus, que vídeo incrível, obrigado por compartilhar seus conhecimentos! me inspiro em você Augusto
Trabalho em TI de banco. Adorei o artigo. Sobre casas decimais e precisão, a Taxa Referencial emitida pelo BACEN todo mês tem um formato como “0,000000123” (a grosso modo). Pode ser inteiro? Isso cria uma complexidade para representar esse tipo de valor onde você precisa criar marcações (com uso do 123E-X) . Eu ainda fico com Decimal e String (tráfego somente).
cara tu poderia dar aula, tu leva jeito pra coisa e poucas pessoas incluindo professores tem esse dom
Cara, eu não tenho conhecimento nenhum sobre isso, mas ficou ótimo o entendimento.. conteúdo top, namoral.
double spend pode ser resolvido com a partida dobrada. Contadores usavam isso no lapis antigamente...
aka double-entry bookkeeping, tu vai ter um sistema muito mais auditável e confiável.
Esses micros lembram também os Satoshis, que em transações de BTC são utilizados para calcular a fee que será paga
pra grande maioria dos casos que passei armazenar como centavos foi uma ótima solução, quando não fiz me arrependi mais tarde. mas não tive nenhum caso com rendimento como mostrou mesmo
Um truque para ledgers: ter uma coluna last_balance atrelado ao registro da carteira. Nem sempre reprocessar um dataset é viável e ter esse número na mão torna alguns números muito mais próximos e baratos.
Galego, você é foda!! Obrigado pela aula!
15:06 Eu fiquei o video inteiro pensando "pô mano mas é obvio que a melhor abordagem é multiplicar o valor por 1000 em toda operação e dividir por 1000 no final da operação". Tipo, não seria 0.03% de 10.00, seria (0.03% de (10*1000))/1000. Satisfatório ver meus pensamentos serem concretizados nesse trecho no vídeo.
Obrigado pelo conteúdo importante e de qualidade!
00:23 me ganhou aqui kkkkk
sobre a conversão, você só converte no dia que fechar o câmbio. Se o banco fecha todo dia, ele converte todo dia, se você é uma empresa de comercial importadora / exportadora, normalmente você faz isso 1x por semana. Você só converte nesse momento, porque é quando você tem o valor do dólar fixado.
uns meses atrás eu tentei pagar meu cartao com saldo na conta (que era o valor exato da fatura) no nubank ele me avisava que eu nao tinha saldo, precisei fazer um pix de 1 centavo de outra conta e consegui pagar a fatura, nao acredito que fintech ainda comete esse erro basico com float...
Vale ressaltar que a escolha do verbo HTTP não dá garantia nenhuma… se a operação não for implementada de forma a garantir idempotência, a escolha de um outro verbo é uma mudança puramente estética. Fazer menção a transações ACID faz muito mais sentido nesse caso.
complemento, da jusbrasil: Cuidado! "Arredondar" pequenos valores poderá caracterizar sonegação fiscal
Ola jovem!! Muito bom o video!! Traz luz a muitos aspectos que normalmente a gente so aprende errando!!
Um ponto que eu acho que nao foi tratado no artigo é a questão de operacoes com ponto flutuante! Muitas linguagens (como Java) tem erros grotescos como por exempo: 0.1 + 0.2 = 0.30000000000000004 !!! Isso parece pouco, mas pode causar diversos problemas, principamente ao longo de milhares de operacoes.
Por isso alguns sistemas precisam tratar valores com classes especificas (como o BigDecimal), ou mesmo criar solucoes como armazenar a um numero decimal como sendo 2 numeros inteiros (o numero antes da virgula e o numero depois da virgula), mas os operadores destes numeros compostos sao bastante complicadas de implementar.
Neste caso linguagens como o COBOL brilham quando comparada ao Java.
A questao do POST vs PUT pode ser resolvida incluindo-se o "ID" em ambas, onde o backend usa este id para identificar unicamente a transacao (entidade).
Enfim... muitas destas coisas a gente so consegue perceber depois de ter passado pelo problema!! Seria muito bom se as pessoas soubessem aprender com os erros dos seus predecessores.
o "erro" do ponto flutuante não é um problema de linguagem é um problema do float em si e como os processadores interpretam esse tipo de dado
@@gssj-o8p Justamente. Esse erro acontece porque o processador não tem a capacidade de representar todos os números reais entre os valores máximo e mínimo que um float ou um double representa.
O problema não é linguagem lindo, é como o ponto flutuante funciona mesmo.
@@Gustavotrestento1 É verdade! Mas eu citei o Java pq isso corre no tipo double dele! Ja em outras linguagens como Cobol e Pascal, este tipo de problema nao ocorre (pode ser que a linguagem ja trate internamente)... da mesma forma que com BigDecimal do java isso tb nao ocorre! Enfim... sao estes tipos de problemas que a propria linguagem ja deveria tratar!!
Em COBOL, a representação padrão é decimal. Com a usage DISPLAY, cada dígito fica armazenado em um byte. Como isso é bastante custoso, é mais comum a usage COMP-3 (PACKED-DECIMAL), que armazena valores decimais na representação BCD, com dois dígitos por byte. Mas ambas opções contornam o problema de arredondamento do ponto flutuante :)
acho que seria legal linkar o conteúdo na descrição
Eu tive que implementar recentemente uma interface na aplicação para trabalhar com 5 gateways financeiros. Eu tive que traduzir a regra de negócio da aplicação para cada gateway. Um trabalhava com int, outro com float, outro decimal... foi uma loucura, principalmente na parte de calcular comissões.
Não se usa ponto flutuante para valores financeiros, se usa inteiros ; se precisar de maior precisão , é só definir um fator de precisão. Simplifica absolutamente tudo: cálculo em plataformas diferentes (postgres, redis, etc) e resolve problemas de símbolos e formatações em integrações.
A explicação dele sobre os inteiros não foi tão boa, mas se você for testar fazer um acréscimo de porcentagem no valor inteiro pode dar errado. No caso que eu tenha 5 reais, que é 500 centavos, se em um dia o rendimento for de 0.03%, vai dar problema, pois 500 * 0.0003 = 0.015 centavos. Como irá colocar isso nos centavos? Aí vai depender do que você irá enfrentar
E alguém tiver solução para isso, eu ficar bastante grato, pq eu mesmo não sei como resolver kkkkkkkkk
@@nikollasdavid7082 "imagine que para armazenar um valor de dinheiro na base de dados, convertemos para centavos, e ainda multiplicamos para um fator de precisão de 1000. Então, R$ 5,00, seria representado como 5*100*1000 = 500000. Como incrementariamos 0,03% a esse valor ?"
Coloca isso no chatgpt, ele vai te explicar.
Trabalhei em um sistema de APIs que cobrava por requests, e os valores eram incrivelmente baixos, tipo R$ 0,000000123. Tinhamos problemas de integração, e problemas de diferença de precisão em calculos - o postgres dava um resultado, no redis dava outro.
No final das contas, percentual por ser representada como uma multiplicação.
E processadores trabalham muito melhor com inteiros, ponto flutuante é problema gratuíto.
Anteriormente também trabalhei em uma operadora de cart]ao de crédito, ele usavam somente centavos em tudo. O PagSeguro também está usando centavos na API deles agora (usavam "moeda" anteriormente).
Representar moeda em forma de inteiro é infinitamente melhor que ponto flutuante.
@@nikollasdavid7082 "imagine que para armazenar um valor de dinheiro na base de dados, convertemos para centavos, e ainda multiplicamos para um fator de precisão de 1000. Então, R$ 5,00, seria representado como 5*100*1000 = 500000. Como incrementariamos 0,03% a esse valor ?"
Coloca isso no chatgpt, ele vai te explicar.
Trabalhei em um sistema de APIs que cobrava por requests, e os valores eram incrivelmente baixos, tipo R$ 0,000000123. Tinhamos problemas de integração, e problemas de diferença de precisão em calculos - o postgres dava um resultado, no redis dava outro.
No final das contas, percentual por ser representada como uma multiplicação.
E processadores trabalham muito melhor com inteiros, ponto flutuante é problema gratuíto.
Anteriormente também trabalhei em uma operadora de cartões de crédito, ele usavam somente centavos em tudo. O PagSeguro também está usando centavos na API deles agora.
Representar moeda em forma de inteiro é infinitamente melhor que ponto flutuante.
@@nikollasdavid7082 Eu uso 4 ou 6 unidades decimais pra garantir que multiplicações e divisões não vão dar problema. Daí é só usar banker's rounding na hora de exibir na tela
@@nikollasdavid7082Isso tem pegado minha mente também
Conteúdo de qualidade 🔥
Veio na hora certa
Quando você entende que quando você corta 1 cabeça de um bicho de 7 cabeças, vira um bixo de 8 cabeças.
Interpretei da seguinte forma "quando você acha que o problema representa 1x, mas após investigar minimamente, descobre que é 2 x"
é a hydra da marvel po, corte uma cabeça, duas nascerão no seu lugar
Acha que controlar timezone ja da problema hoje, imagina quando começar exploração espacial e tivermos que considerar o time de outros planetas rsrsrsrs
14:14 - Mais decimal que Bitcoin?
Até onde eu saiba, decimal é inteiro. As operações aritméticas com decimal não usam ponto flutuante, o que garante uma precisão maior.
Não sei se já tem vídeo no canal, mas seria interessante falar sobre representação de dados no computador. O que um inteiro? O que é um float? Como o computador soma floats?
na verdade, eyu sempre usei inteiros porem, uso tabelas auxiliares justamente para evitar isso da aplicação de render 0,003 ou mesmo sei la um serviço ao mês custa 30 reais, mas tenho que calcular por hora/uso... até porque, inteiro tu tem precisão, doubles/ decimal tu perde precisão, mas pra alguns casos financeiro, tabelas auxiliares e seguindo o padrão lá acho que é da abnt ou é outro orgão que eu não lembro o nome, tu padroniza, nem que faça checagem de valores enfim..
Qual é o software que ele usa para desenhar ?
Meus usuários são guardados em uma grande String no bloco de notas.
Se modelar uma aplicação com juros diários, não iria armazenar no banco o valor presente de cada dia, vc armazena o principal, a data do investimento e a taxa de juros e calcula o valor presente em runtime.
Há cenários que são essenciais contabilizar diariamente, lançar os devidos débitos/créditos correspondentes
cade o link do post
Na questao de contabilidade o SAP da aulas.
Muito bom! Valeuuu
Na verdade, quando se taxas e rendimentos sobre o montante, não é uma boa prática somar diretamente no montante. Isso causa erros de arrendamento e , somados esses erros, Causa uma imprecisão gigantesca com valores muito altos ou uma cardinalidade grande de números pequenos. disso não tem como escapar. Invés disso, vc marca os dias que tal taxa atuou, a data que vai agregar e soma apenas no final ao apresentar o resultado
Acho que o ledger seria um event sourcing ….
Qual nome desse site que vc fica fazendo esses desenhos?
Excalidraw
"eu me impressionei pelo tanto que expliquei" [ahhahaha lembrou aquela máxima] "o sábio aprende com o erro dos outros"
Faltou colocar o link do Post
Coloco como inteiro sempre, 12999 vira R$129,99. 7990 vira R$79,90 e é isso.
Alguém sabe de algum material para aprofundar nesse assunto de tratamento de dados em fintech?
Java -> toma aqui BigDecimal 💀
ah então por isso ele é tão usando no sistema bancaário
qual relógio é esse ?
complemento artigo de Mauro Negruni: Diferença de Centavos é insignificante
Vai ter Black Friday?
Apenas por curiosidade.. tu é torcedor do santa cruz? kk
oxi, mas não precisa separar os centavos... tu transforma o valor todo pra inteiro.
Ó
timo Video
Bom demais
Conteúdo estilo Lucas Montano, porém com algo interessante
Top
tooppppp demais
🎉🎉
Eu até pedi para o Sr. Akita fazer um vídeo sobre esse assunto, mas desconfio que ele também não sabe.
Basta salvar o valor como inteiro (centavos).
Tem o problema dos rendimentos, multiplicar por uma porcentagem, ex: 300 reais, rendeu 1,08% vira R$ 303,24 inteiro perderia a fração. Precisaria usar dois inteiros, um para a "parte fracionária" (com vários zeros à direita para ter precisão) e outro para a "parte cheia" do valor? Teria que usar algo da linguagem, BigDecimal, Decimal inicializando com string pra não ter confusão.
bitcoin resolve todos esses problemas kkk
Fintechs = arquitetura orientada a eventos 🤔
Não só registrar uma transação em uma linha no banco de dados, mas também as alterações que ela teve usando Kafka ou RabbitMQ