From Microsites to Context-Driven Architecture: Lessons Learned

Fabio Arcari — Fri, 05 Sep 2025 21:15:27 +0000

From 12 separate microsites to 6 context-specific ones: the web architecture powering subito.it, Italy’s leading online classifieds platform, and the lessons we learned from overengineering.

Introduction

Four years ago, at subito.it, we had fully embraced the microsite approach.
Every page or small group of pages had its own repository, its own deploy pipeline, and its own infrastructure.
It was the era of the article "Our microsite architecture" published on Adevinta's tech blog, where we proudly described how we had "accelerated the frequency of releases and the independence of teams by applying a microsite approach."

What is a Microsite?

A microsite is an architectural approach where individual pages or small groups of related pages are developed, deployed, and maintained as completely separate applications.
Each microsite typically has its own:

Repository and codebase
CI/CD pipeline and deployment process
Infrastructure and hosting environment
Technology stack (which can differ from other microsites)
Team ownership and responsibility

This approach contrasts with traditional monolithic applications where all pages are part of a single large codebase.
Microsites aim to provide maximum team autonomy and deployment independence, allowing different teams to work on different parts of a website without interfering with each other.

Today, in 2025, we have an update on this architecture: we've found a better balance between agility and maintainability through continuous learning and optimization

The Microsite Era: When Everything Seemed Perfect

The microsite approach we had adopted seemed like the ideal solution for our problems:

Lean pipelines: each microsite had a fast and independent deploy pipeline
Team autonomy: each team could work on their own piece without interference
Independent releases: no mutual blocking between teams

Over time, however, we started noticing the first issues:

Uncontrolled Repository Proliferation, what had started as a strategy for important pages had begun to be applied to secondary pages as well.
Distributed Technical Debt, with 12 repositories to maintain, some pages started falling behind in dependency updates and security patches
Excessive Infrastructure Overhead, each microsite required:
- Monitoring configuration
- Alerting setup
- Pipeline maintenance
- CDN Configuration

The New Strategy: Context-Driven Microsites

Instead of going completely back to a monolith (which would have reintroduced the problem of overly long pipelines), we chose a middle path: context-specific microsites.

Principles of the New Architecture

Context First: we group pages that share the same business domain
Clear Ownership: each microsite remains owned by a specific team
Manageable Size: large enough to justify the infrastructure, small enough to remain maintainable

Our new architecture consolidates related pages into context-specific groupings:

Public Content Hub: All public content pages and SEO-relevant content
Ad Insertion Flow: The entire ad insertion workflow
Authentication Service: Authentication, login and sign-up
Transaction Service: The entire transaction ecosystem
Paid Options Service: Paid services and premium options
User Management Service: Personal area and profile management

The Transition Process

Our migration follows a structured approach with three main phases:

Phase 1: Preparation and Setup
The initial phase focuses on preparing the target microsite to receive the migrated functionality:

Set up dedicated layouts and components in the target architecture
Import and adapt components to the consolidated codebase
Update environment variables and configuration management
Establish monitoring and alerting for the new consolidated service

Phase 2: Quality Assurance and Testing
Before going live, we conduct comprehensive checks:

Execute automated end-to-end (E2E) and manual tests
Validate third-party integrations (e.g., GTM)
Verify page headers, caching policies, and security configurations
Confirm monitoring and metrics collection are correctly implemented

Phase 3: Production Migration and Cleanup
The final phase involves the actual cutover and decommissioning of legacy systems:

Gradual Rollout:

Route traffic progressively from legacy to consolidated microsite
Monitor performance and error rates during the transition

Legacy Cleanup:
Following our established Service End-of-Life procedures, we systematically decommission the old microsite:

Destroy monitoring, alerts, and dashboards
Archive repositories and remove deployment configurations
Clean up infrastructure resources (databases, IAM roles, etc.)
Update routing and add redirects where necessary

Conclusions

Our journey from microsites to a more consolidated approach wasn't a failure of microsite architecture, but rather a maturation of our understanding of when and how to apply it.

What we learned:

Architecture must evolve with business and team needs
Not everything needs to be a microservice/microsite - like any architectural pattern, it has its trade-offs
Context is fundamental, group by business context, not technical convenience
Pages that belong to the same user flow should probably stay together

Today, with our 6 context-driven microsites, we've found a balance that allows us to maintain team autonomy and deployment speed while significantly reducing maintenance overhead.

The path to perfect architecture doesn't exist, but the path to ever-improving architecture does.

Forem: Fabio Arcari