From Independent Microsites to Context-Driven Architecture

How we moved from 12 separate repositories to 6 context-specific microsites, learning from over-engineering challenges

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:

1. Uncontrolled Repository Proliferation, what had started as a strategy for important pages had begun to be applied to secondary pages as well.
2. Distributed Technical Debt, with 12 repositories to maintain, some pages started falling behind in dependency updates and security patches
3. 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

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

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

1. Public Content Hub: All public content pages and SEO-relevant content
2. Ad Insertion Flow: The entire ad insertion workflow
3. Authentication Service: Authentication, login and sign-up
4. Transaction Service: The entire transaction ecosystem
5. Paid Options Service: Paid services and premium options
6. 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.