When a leading online retail platform reached out to Nyala, they faced a major challenge: their current search experience was outdated, tightly coupled with a third-party search vendor, and difficult to maintain or upgrade. They needed an MVP that would explore a new AI-powered search provider and act as the foundation for a larger shift toward a modern, serverless architecture.

Khalid from Nyala was brought in to lead this initiative, not only to build the MVP but also to mentor the team on best practices in Next.js, TypeScript, and scalable architecture.

Discovery Phase: Diagnosing the Pain Points

Khalid spent the first couple of months embedded with the team, analysing the existing setup, gathering requirements, and mapping out what needed to change. It quickly became clear that the best approach was to extract the search experience into a standalone application, allowing for more flexibility, easier upgrades, and a clean integration with newer technologies.

Next.JS Serverless Architecture Diagram

Why Serverless + Next.js?

The client was keen on going serverless but wanted to remain within the Node.js ecosystem while preserving SEO capabilities and the ability to handle high traffic loads. Next.js was the ideal choice.

To justify the architectural direction, Khalid drafted a KDD (Key Design Decision) document outlining various solutions, evaluating the trade-offs of each. After internal discussions with the leadership and architecture teams, AWS Lambda was chosen as the deployment target — specifically using the AWS Lambda Web Adapter to support standalone Next.js apps.

Canary Release Support

A canary release is a software deployment strategy that rolls out changes to a small subset of users before making it available to everyone. This approach reduces risk by allowing teams to monitor the new release in a real-world environment, catch issues early, and ensure stability before a full rollout.

To support canary releases in this project, we implemented a strategy using AWS Lambda versions and aliases, API Gateway, and CloudFront:

• Each time a new release or feature branch is created:

  • A new Lambda version is published.

  • An alias is created to point to this version.

  • A new path is added in the API Gateway, mapping to that specific alias.

• On the frontend, CloudFront, with the help of CloudFront Functions and cookies, orchestrates routing:

  • It can direct users to a specific feature path (e.g. for QA or staging).

  • Or it can point to a latest path, which always routes to the latest stable build.

This approach offers multiple benefits:

• Enables independent testing of feature branches in production-like environments.

• Makes rollback and cleanup easy — just remove the corresponding path and alias.

• Provides a clear separation between stable and in-development builds.

Decoupling from the Search Vendor

One of the project's primary goals was to eliminate vendor lock-in. The original application was deeply entangled with a specific search provider, making it difficult to swap out or upgrade technologies.

To solve this, the new system was split into two core components:

• Search UI (Next.js) — responsible for rendering and user interaction

• Search Services (Express.js) — responsible for interfacing with the search provider(s), defining the contract, and aggregating all necessary data

This design ensured that the front end remained agnostic of the back-end implementation, offering much more flexibility.

Successful MVP Delivery

The MVP was completed in just five months. It was load-tested using industry-standard tools, and the results were highly promising. The system not only demonstrated high performance under pressure but also laid a robust, scalable foundation for future development.

By decoupling components, embracing serverless infrastructure, and incorporating modern deployment techniques like canary releases, Nyala helped this retailer rethink how search could work at scale. The project is a strong example of our hands-on, iterative approach to solving real-world problems with pragmatic engineering.