vamos la
quando vc quer fazer algo voltado para a web, entra em questão a questão da escalabilidade.
é um site de noticias? é um site de compras? rede social?
vc vai reparar que, dependendo do tipo de site que estamos falando, vc talvez tenha partes dele que mudam pouco ou quase nunca, ou seja, que pedem quase nada de interatividade.
veja um produto exposto numa loja, ou numa noticia: vc apenas consome essas coisas, no maximo vai colocar em um carrinho e vai pagar depois. isso não muda que um sapato ou uma noticia vão continuar os mesmos por muito tempo ( ok, a noticia pode ser atualizada, ou o sapato pode ter estoque esgotado, mas isso não é frequente e isso é decidido por um grupo bem menor de pessoas ).
dito isso, vc tem sistemas cujo acesso é o mais importante. e se vc acessa varias vezes a mesma coisa, sem muita personalização ou interatividade, vc deve usar cache com inteligencia e precisão.
claro que vc pode usar um cloudflare da vida, ou lidar com o cache do NginX ou apache na frente da sua aplicação, nesses casos vc precisa apenas de um framework que te permita controlar bem o cabeçalho HTTP, o que a maioria permite.
porem o que geralmente se faz é usar um sistema pronto e customiza-lo (o que pode chegar a reescrever parte da solução). existem sistemas de e-commerce, CMS, CRM, etc, por ai de todos os preços ( inclusive de graça ).
por exemplo, vc pode imaginar um site de noticas como sendo paginas que mudam de hora em hora de acordo com alguma configuração e o link para as noticias podem ser simplesmente o html estatico gerado a primeira vez ( e ai entra o nosso amigo mod_rewrite por exemplo ). ai vc tem noticias de 10 anos cujo codigo que gerou aquilo ja foi pra casa do chapeu.
Vou te dizer que um site de noticias atualizado de hora em hora esta mais pra um crontab que gera html e salva em disco do que pra um site feito com JSF - o que não significa que vc deva descartar JSF, apenas pense que com uma montanha de acesso, é mais facil servir um .html do que processar uma servlet. E ainda tem opções de customização via javascript, css, server side include, iframes, etc.
é uma engenharia mais complexa. só isso.
Edit: a maioria desses sites são compostos de dois sistemas
-
o “admin” onde vc cadastra as coisas
-
o sistema que gera o html final.
a integração entre eles pode ser via banco de dados ( o que pode gerar uma série de inconvenientes ao longo do tempo ) ou usando uma API ( REST por exemplo ).
não é incomum vc ter um terceiro sistema: um mecanismo de busca customizado ( que pode ser o google custom search, pode ser ElasticSearch, etc ).
um grande site vai ter na verdade N sistemas colaborando entre si, por exemplo vc vai querer ver metricas de desempenho e acesso. E por ser um sistema distribuido em N maquinas a arquitetura disso deve evitar single point of failure , deve permitir load balance e por ai vai. e vc tem que investigar que componentes vão buscar e quais serão atualizados ( pull versus push ). conforme cresce em complexidade e numero de acessos, mais soluções diferentes vc pode precisar. O que não significa que vc vai precisar – aqui entra o problema do BDUF ( big design up front ), onde se adiciona coisas desnecessarias achando que o sistema não vai aguentar a carga sem evidencia material, ou prevendo uma carga que jamais sera alcançada.
Perceba que com o a solução de cache correto, seu site pode ser feito até em shell script/ cgi bin / php / java/ perl / cobol / qq coisa que cuspa html.