{"id":4130,"date":"2022-05-09T19:37:13","date_gmt":"2022-05-09T22:37:13","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=4130"},"modified":"2024-01-11T18:04:39","modified_gmt":"2024-01-11T21:04:39","slug":"iniciando-o-design-arquitetural-de-um-encurtador-de-urls-v-1-1","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-encurtador-de-urls-v-1-1\/","title":{"rendered":"Iniciando o design arquitetural de um “encurtador de URLs”"},"content":{"rendered":"

Conhecimento, ganha-se estudando. Entendimento, ganha-se refletindo sobre algo estudado. Sabedoria, ganha-se com a pr\u00e1tica.<\/strong><\/p>\n

Nesse cap\u00edtulo, usaremos alguns dos conceitos discutidos nesse livro para iniciar a elabora\u00e7\u00e3o do design<\/em> arquitetural de um encurtador de URLs. Iremos tratar, obviamente de um cen\u00e1rio fict\u00edcio.<\/p>\n

O que \u00e9 um “Encurtador de URLs”<\/h2>\n

URLs longas s\u00e3o mais dif\u00edceis de lembrar, manter e compartilhar. O encurtamento de URL \u00e9 uma t\u00e9cnica, adotada frequentemente, para transformar endere\u00e7os HTTP em links mais curtos.\u00a0<\/strong><\/p>\n

O encurtamento de URLs ganhou destaque, primeiro, com a populariza\u00e7\u00e3o do Twitter – onde, originalmente, havia um limite de 140 caracteres por postagens. A ideia original era “economizar” caracteres nas URLs compartilhadas para permitir a adi\u00e7\u00e3o de mais informa\u00e7\u00f5es em um tu\u00edte. Atualmente, a plataforma j\u00e1 oferece esse recurso built<\/em>-in.<\/em><\/p>\n

Alguns servi\u00e7os para encurtamento de URLs geram estat\u00edsticas de acessos a partir dos links<\/em> encurtados. Tamb\u00e9m tem se tornado comum permitir a personaliza\u00e7\u00e3o da URL curta, facilitando a leitura.<\/p>\n

A ado\u00e7\u00e3o de um encurtador de URL pode tornar o acesso a um site perceptivelmente mais lento, devido a necessidade de mais requisi\u00e7\u00f5es HTTP e DNS.<\/p>\n

Coletando informa\u00e7\u00f5es para o Haiku<\/h2>\n
\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Architecture Haiku<\/p>\r\n

N\u00e3o sabe o que \u00e9 um “Architecture Haiku”? Consulte agora esse t\u00f3pico no cap\u00edtulo em que tratamos sobre documenta\u00e7\u00e3o de software.<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Designs<\/em> arquiteturais devem atender os objetivos do neg\u00f3cio, respeitando restri\u00e7\u00f5es, satisfazendo atributos de qualidade, mitigando riscos e reduzindo custos. N\u00e3o h\u00e1 trabalho de arquitetura sem explicita\u00e7\u00e3o dos requisitos do neg\u00f3cio.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Em nosso “cen\u00e1rio fict\u00edcio”, as pessoas do neg\u00f3cio t\u00eam (para variar) a expectativa de lan\u00e7ar o servi\u00e7o no menor prazo poss\u00edvel. Algumas j\u00e1 atuaram em empresas que forneciam servi\u00e7os semelhantes, por isso, tem bom conhecimento do que funciona e n\u00e3o funciona na \u00e1rea.<\/p>\n

As principais features<\/em> do servi\u00e7o, segundo descrito pelas pessoas do neg\u00f3cio, s\u00e3o:<\/p>\n

    \n
  1. Encurtar URLs; ou seja, fornecida uma URL longa pelo usu\u00e1rio, gerar uma URL muito menor.<\/li>\n
  2. Redirecionamento r\u00e1pido; ou seja, acessada uma URL encurtada, gerada pela plataforma, redirecionar o usu\u00e1rio para a URL original<\/li>\n<\/ol>\n
    \n

    Infere-se, por caracter\u00edsticas do que se est\u00e1 oferencendo, que os atributos disponibilidade<\/span>, escalabilidade<\/span> e resili\u00eancia<\/span> s\u00e3o aqueles que se destacam.<\/p>\n

    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\"\r\n

    Atributos de qualidade<\/p>\r\n

    Disponibilidade, escalabilidade e resili\u00eancia s\u00e3o tr\u00eas atributos de qualidade. Quer relembrar o conceito? Consulte agora o t\u00f3pico onde o explicamos.<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

    N\u00c3O<\/span><\/strong> h\u00e1 expectativa de gerar estat\u00edsticas, permitir altera\u00e7\u00e3o ou exclus\u00e3o de URLs inseridas na plataforma, tampouco permitir customiza\u00e7\u00e3o das URLs geradas.<\/p>\n

    \r\n

    Defini\u00e7\u00e3o: Requisito inverso<\/p>\r\n

    Requisito Inverso \u00e9 uma descri\u00e7\u00e3o para demandas em uma especifica\u00e7\u00e3o de escopo negativo, <\/strong>ou seja, de algo que n\u00e3o ser\u00e1 feito ou ou expectativa que n\u00e3o ser\u00e1 atendida.<\/p>\r\n<\/div>\n

    Estimam-se 10 milh\u00f5es de novas URLs sendo encurtadas diariamente. O formato da URL encurtada dever\u00e1 ser www.abc.com\/<id><\/code>. Sendo que a parte id<\/code> deve ser uma cadeia o mais curta poss\u00edvel compostas por n\u00fameros (0-9) e letras (a-z, A-Z).<\/p>\n

    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\" N\u00e3o \u00e9 poss\u00edvel discutir escalabilidade e disponibilidade com nenhuma estimativa relacionada a workloads<\/em>.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

    Algumas estimativas de “papel de p\u00e3o”<\/h2>\n

    Com base nas informa\u00e7\u00f5es levantadas com o neg\u00f3cio, em nosso cen\u00e1rio fict\u00edcio, \u00e9 poss\u00edvel elaborar algumas estimativas, grosseiras, mas j\u00e1 suficientes para orientar algumas decis\u00f5es de design.<\/em><\/p>\n

    A ideia n\u00e3o \u00e9, necessariamente, chegar a precis\u00e3o decimal, mas “compartilhar a vis\u00e3o” de n\u00fameros mais tang\u00edveis e come\u00e7ar a estabelecer restri\u00e7\u00f5es.<\/p>\n

    \"\"<\/p>\n

    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\" A propor\u00e7\u00e3o de 10 para 1 em opera\u00e7\u00f5es de leitura e grava\u00e7\u00e3o \u00e9 uma refer\u00eancia segura, embora conservadora, para a maioria dos cen\u00e1rios. Serve, pelo menos, como um bom ponto de partida.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

    Eventualmente, \u00e9 interessante discutir com o neg\u00f3cio sobre poss\u00edveis sazonalidades, como hor\u00e1rios com volumes de uso mais altos.<\/p>\n

    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\" Pessoas do “neg\u00f3cio” t\u00eam tremenda validade de “apontar os n\u00fameros”. Da\u00ed, a import\u00e2ncia de criar um referencial, mesmo que impreciso, como ponto de partida, buscando obviamente aprimor\u00e1-los com o andamento do projeto.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

    Para come\u00e7ar a dimensionar infra, \u00e9 importante considerar que os recursos alocados podem estar “consumidos” at\u00e9 80% durante a execu\u00e7\u00e3o para evitar riscos de exaust\u00e3o.<\/p>\n

    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\" Sempre explicite desdobramentos associados a carga de trabalho que est\u00e1 sendo projetada. Isso facilita no alinhamento do time e no estabelecimento de fitness functions<\/em>.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

    A partir da carga identificada, \u00e9 poss\u00edvel determinar algumas fitness functions.\u00a0<\/em><\/p>\n

    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\"\r\n

    Architectural fitness function<\/p>\r\n

    Architectural fitness functions s\u00e3o fundamentais para o desenvolvimento de arquiteturas evolutivas. Relembre o conceito<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

    Organizando informa\u00e7\u00f5es para gerar as primeiras ADRs<\/h2>\n
    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\"\r\n

    Architecture Decision Record<\/p>\r\n

    O bom arquiteto garante que decis\u00f5es sejam tomadas, justificadas e comunicadas! Precisa relembrar o que \u00e9 uma ADR? Visite o t\u00f3pico onde introduzimos o conceito.<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

    A partir das informa\u00e7\u00f5es obtidas para formula\u00e7\u00e3o do Haiku<\/em> e dos “n\u00fameros no papel de p\u00e3o”, j\u00e1 \u00e9 poss\u00edvel indicar algumas ADRs em status de “aberta para discuss\u00e3o”. Essas ADRs indicariam a “inclina\u00e7\u00e3o arquitetural” para diversos aspectos importantes, possibilitando debates com especialistas.<\/p>\n

    Endpoints<\/h4>\n

    Parece ser adequado desenvolver o servi\u00e7o como uma API REST. Destacam-se dois endpoints<\/em> principais.<\/p>\n

      \n
    1. Encurtamento de URL com POST www.abc.com\/shorten?url=<long-url><\/code><\/li>\n
    2. Redirecionamento com POST www.abc.com\/<short-url><\/code><\/li>\n<\/ol>\n

      Redirecionamentos<\/h4>\n

      H\u00e1 duas op\u00e7\u00f5es b\u00e1sicas de redirecionamento em HTTP:<\/p>\n