[Dúvida] - PayloadLocation - Identificador numérico

[fernandogodoy]

Olá, notei que nos endpoint de Location, os IDs são numéricos Int32.

{
  "id": 7716,
  "location": "pix.example.com/qr/v2/2353c790eefb11eaadc10242ac120002",
  "tipoCob": "cob",
  "criacao": "2020-03-11T21:19:51.013Z"
}

Id da locationinteger($int32)

Gostaria de saber se existe algum motivo para uso desta forma e não optar por uma abordagem utilizando um UUID visto que ele é baseado na RFC 4122 e dessa forma teriamos um melhor controle de colisão entre os identificadores?

[ninrod]

Gostaria de saber se existe algum motivo para uso desta forma e não optar por uma abordagem utilizando um UUID visto que ele é baseado na RFC 4122 e dessa forma teriamos um melhor controle de colisão entre os identificadores?

Nenhum motivo em especial. Inclusive, se você tivesse informado esse exato argumento antes de lançarmos a 2.1.0 eu teria concordado, apesar de achar que para essa feature específica, bilhões de locations por usuário recebedor estaria suficiente.

Mas agora, "esse navio já partiu".

[fernandogodoy]

O problema não é nem a quantidade e sim o tratamento de identificadores sequencias numericos e unicos em sistemas distribuidos.

Mas ok, alguma possibilidade de isso entrar como melhoria em versões futuras?

[ninrod]

Mas ok, alguma possibilidade de isso entrar como melhoria em versões futuras?

Possibilidade total. O problema, no momento, é que não podemos de maneira alguma pensar em mudanças que "quebrem" as implementações. Se não fosse isso, sua sugestão já estaria no master.

[fernandogodoy]

Se desse pra fazer enquanto ainda estamos no começo ainda, acredito que seria um impacto pequeno, poderia entrar na 2.2 iria ajudar muito ter isso na API.

[renatofrota]

Essa política de "não poder quebrar" é bastante difícil de ser seguida quando muitas coisas entram em produção antes que o mercado tenha tempo suficiente para avaliar o impacto das decisões. 😢

E, quebrar por quebrar, outras coisas mais relevantes já se quebraram no caminho dos updates recentes. 😝

Como argumento: por mais que o tipo de dado seja diferente, é uma quebra de menor impacto, considerando-se que o ID é gerado pelo PSP (resultado de POST) e não pelo EC (resultado de PUT).

[renatofrota]

Ainda pensando no que eu mesmo disse acima, o fato de ser um ID incremental e não uuid não afetaria o paralelismo para o EC, sendo um POST e não um PUT (ele só vai saber o ID a partir do retorno do POST, seja qual for o formato do ID). Mas com base no perfil do @fernandogodoy acho que a preocupação dele quando diz "sistemas distribuídos", está pensando no lado do PSP.

[fernandogodoy]

Sim, a quebra seria mais dificil de se manter pensando no tipo inverso, mudar de String para Numérico dado que alguns dos ids poderiam ter sido gerados com alfanumericos. Mas como a proposta é inversa, mudar de Numérico para String, acredito ser mais fácil de ser contornado.

Exatamente @renatofrota quando identificadores não são tratados como número temos maior flexibilidade pra estilos arquiteturais baseados e microserviços com ou sem eventos.

Assim temos maneiras de pensar na escala desses serviços e em formas de não afetar os clientes com indisponibilidades, e, sim pensando no lado do PSP que é quem neste cenário, tratará todo o controle de criação das cobranças, bem como, processamento dos pagamentos e devoluções.