When and How Should You Evolve Your Website Architecture?

Why does website architecture evolve? The author identifies two driving forces: an internal desire to improve current business and develop new services, and external pressures from growing user volume and diversity.

Understanding the external structure (U‑N‑S‑C) helps pinpoint when evolution is needed:

U : User base – dimensions include quantity, type, and geographic location.

N : Network environment – varies by region, motivating the use of CDNs for consistent user experience.

S : Security – the required level depends on the site’s stage and nature.

C : The website itself – the internal structure.

The internal structure consists of:

A : Application services.

D : Data services.

These components form a baseline for evaluating whether and how to evolve a website.

Evolution Process and Common Issues

Initial stage – a single server may suffice for a small site.

Separate data and application services – as users grow, split services, allocate stronger CPUs to application servers and larger disks to data servers.

Introduce caching – cache the hot 20% of data (local or distributed) to boost performance.

Deploy server clusters – when a single server hits its limits, add load‑balancing and clustering.

Clustered environments raise session‑management challenges, with options such as:

Session sticky – keeps a user on the same server (issues: loss on restart, stateful load balancer).

Session replication – copies session data to all nodes (issues: bandwidth, memory consumption).

Cookie‑based – stores session identifier in a cookie (issues: size limit, security, bandwidth, processing overhead).

Dedicated session server cluster (issues: availability and application changes).

Database read/write splitting – offload reads to replica slaves to alleviate read bottlenecks; requires an abstraction layer so application code remains unaware of the split.

Challenges include data replication latency, routing logic, and cross‑datacenter considerations.

Reverse proxy and CDN – improve global response times by caching static resources at edge locations.

Distributed file system

Dedicated databases (vertical sharding) – split data by domain to reduce write contention.

Vertical sharding introduces cross‑business transaction complexity and additional configuration.

Horizontal sharding – partition a large table across multiple databases.

Issues include routing logic, primary‑key strategy, and pagination performance.

Other techniques mentioned: search engines for query acceleration, selective NoSQL use, unified data‑access modules, and business/application decomposition.

Ultimately, architecture evolution is not a fixed sequence; decisions depend on current bottlenecks, business priorities, and organizational readiness. Cloud environments simplify resource scaling, but architectural principles remain the same.