Project Cuculi: A Strategic and Technical Blueprint for a Smart, Nudge-Based Notification System

Author: Chris Cruz

Length: • 25 mins

Annotated by Chris

Project Cuculi: A Strategic and Technical Blueprint for a Smart, Nudge-Based Notification System

Section 1: Executive Summary & Strategic Foundation

1.1. Project Mandate

This report outlines a strategic and technical blueprint for the development and implementation of a smart notification system for the social dining application, Cuculi. The primary business objective of this initiative is to significantly increase user conversion, specifically targeting the critical user journey from initial app download to their first confirmed RSVP for a dining event.

1.2. Core Thesis

The proposed solution is a context-aware, hyper-personalized notification system engineered to drive user action. This system will be constructed upon a scalable, event-driven microservices architecture. Its effectiveness will be rooted in the principles of behavioral science, specifically Nudge Theory, and amplified by the predictive and generative power of Artificial Intelligence (AI). The system is designed to deliver timely, relevant, and subtly persuasive communications that guide users toward discovering and committing to dining experiences that align with their interests.

1.3. Strategic Approach

Recognizing the need for both immediate impact and long-term innovation, the implementation will follow a phased approach. This strategy allows for the rapid delivery of business value while progressively building towards a state-of-the-art engagement platform. The journey begins with a fast-to-market, rule-based system and matures into a sophisticated, AI-driven ecosystem, culminating in a vision for interactive, agent-based communication.

1.4. Expected Outcomes

The successful execution of this project is projected to yield several key business outcomes. The primary metric of success will be a measurable increase in RSVP rates among new and existing users. Secondary benefits include enhanced user engagement and improved long-term retention, driven by a more personalized and valuable app experience. Furthermore, the system will generate a rich dataset, providing a deeper, data-driven understanding of user preferences and behaviors, which will inform future product development and marketing strategies.

Section 2: The Psychology of Engagement: Applying Nudge Theory to Dining RSVPs

2.1. Introduction to Digital Nudging

At its core, nudge theory posits that subtle changes in the environment where choices are made can predictably alter human behavior without forbidding any options or significantly changing their economic incentives.1 This concept is grounded in the understanding that human decision-making is not always a rational process. It is frequently influenced by cognitive biases, emotional states, and social context.3 By redesigning this "choice architecture," digital products can gently guide users toward decisions that are beneficial for them, such as discovering a new social event.1

The ethical framework for this approach is known as "Libertarian Paternalism".1 It is "paternalistic" in that it aims to steer users toward outcomes that improve their welfare (e.g., finding enjoyable dining events and connecting with others). It is "libertarian" because it preserves the freedom of choice; users are nudged, not forced, and can easily ignore the prompt.3 For Cuculi, this means designing notifications that are helpful and persuasive rather than intrusive or manipulative. To maintain user trust, all nudges must be subtle, rigorously tested through methods like A/B testing, and transparent in their intent.1

2.2. Crafting Nudges for Cuculi

Translating these behavioral principles into concrete notification strategies is key to increasing RSVP conversions. The following nudges are particularly well-suited for a social dining application.

  • Personalization & Social Proof: These are the most potent nudges for a social platform like Cuculi. Research shows that users are significantly more receptive to messages that are tailored to their specific identity, preferences, and past behaviors.6 Combining this with social proof—the tendency for people to adopt the actions of others in an attempt to reflect correct behavior—creates a powerful persuasive effect.7
  • Implementation Example: Instead of a generic alert, a personalized nudge would read: "A new Peruvian Ceviche event just opened up, which we know you'll love." To add social proof, the message could be: "5 of your friends are interested in the 'Taste of Italy' event this Friday. Want to join them?" This leverages the user's established interests and the implicit recommendation of their social circle.
  • Scarcity & Urgency: The perception of limited availability increases an item's desirability and prompts faster decision-making.6 This is a classic and effective principle in event-based marketing.
  • Implementation Example: Notifications can create a sense of urgency with messages like, "Only 3 spots left for the 'Rooftop BBQ'!" or create a time-bound call to action with, "RSVPs for this exclusive dinner close in 2 hours."
  • Framing & Loss Aversion: The way information is presented has a dramatic impact on perception. People are more motivated to avoid a loss than to acquire an equivalent gain.7 Notifications should be framed around the positive experience the user might miss out on, rather than the task they need to complete.
  • Implementation Example: A message framed with loss aversion, such as "Don't miss out on a unique dining experience with Chef Ana," is more compelling than a direct command like "RSVP for the event with Chef Ana."
  • Gamification & The Goal Gradient Effect: People are more motivated to complete a task as they get closer to a goal. Visual indicators of progress, like the profile completion bar on LinkedIn or daily streaks on Duolingo, effectively leverage this effect.6
  • Implementation Example: Cuculi can introduce a "Foodie Profile" with a checklist of actions to complete (e.g., "Add a dietary preference," "RSVP to your first event," "Review an event"). A visual progress bar showing how close the user is to achieving an "All-Star Foodie" status can nudge them toward the key conversion action of RSVPing.
  • Defaults: The power of inertia means people tend to stick with pre-selected options.1 While less applicable for a single notification click, this is a vital principle for designing the app's settings screens. For instance, users can be defaulted into receiving "Smart Recommendations," requiring them to actively opt-out rather than opt-in, which can significantly increase the reach of the personalized notification system.

2.3. Channel Strategy: Push Notifications vs. SMS - A Hybrid Approach

The choice of communication channel is not merely a technical detail but a strategic decision that balances engagement, urgency, cost, and user experience. An analysis of the primary channels, push notifications and SMS, reveals that a hybrid, multi-channel strategy is essential for maximizing RSVP conversions.

  • Analysis of Channels:
  • Push Notifications: This channel is a powerful tool for driving in-app engagement.8 Push notifications are highly cost-effective, can include rich media like images and interactive buttons, and are instantly recognizable with the app's logo.9 Their primary weaknesses are their dependency on an internet connection for delivery and the ease with which users can disable them.11 Performance data indicates an average open rate of approximately 50% and a click-through rate (CTR) of around 10%.12
  • SMS: This channel's greatest strength is its reliability and immediacy. With open rates approaching 98%, SMS messages are almost guaranteed to be seen by the user and do not require an internet connection.10 This makes SMS the ideal channel for time-sensitive and critical alerts.8 However, its capabilities are limited to plain text with strict character counts, and it incurs a per-message cost that can become significant at scale.11
  • The Strategic Imperative for a Hybrid Model:Relying on a single channel introduces unacceptable risk. A push notification, despite its rich content, has a roughly 50% chance of being opened, which is a significant gamble for a time-sensitive conversion like an event RSVP.12 Conversely, while SMS guarantees visibility, its higher cost and more personal nature make it unsuitable for all communications.11 This is not an either/or dilemma. The most effective strategies use these channels in tandem, creating conditional workflows that adapt to user behavior.8 The notification system must therefore be architected not just to send a message, but to orchestrate a communication sequence across multiple channels based on user interaction—or the lack thereof.
  • Recommended Strategy for Cuculi:
  1. Initial Nudge (Push Notification): The first point of contact for a new event recommendation should be a push notification. It is visually engaging, branded, and low-cost, making it perfect for generating initial interest. For example: "A new Sushi Making class that matches your interests is now available! Tap to see details.".8
  2. Urgency Nudge (SMS Fallback/Escalation): If a user does not interact with the initial push notification (i.e., does not click it within a set timeframe) and the event is approaching or nearing capacity, the system should automatically escalate to SMS. This leverages the reliability and perceived urgency of a text message. For example: "Hi [Name], just a reminder that the Sushi Making class you were interested in is tomorrow and has only 2 spots left. RSVP here: [link]".8
  3. Transactional Messages (SMS): All critical, non-marketing communications, such as RSVP confirmations, payment receipts, or critical event updates (e.g., cancellations), should be sent via SMS. This ensures guaranteed delivery and reinforces user trust in the platform.8

Section 3: System Architecture: A Scalable Microservices Blueprint

3.1. Architectural Principles

To meet the demands of a real-time, high-volume, and intelligent notification system, the architecture will be founded on a set of modern design principles:

  • Microservices: The system will be decomposed into a suite of small, independent, and loosely coupled services.13 Each service will have a specific business responsibility, such as ingesting events or managing user preferences. This modularity enhances scalability, improves fault isolation, and allows development teams to build, deploy, and scale their respective services autonomously.
  • Event-Driven and Asynchronous Communication: The services will communicate primarily through an asynchronous, event-driven model.14 Instead of making direct, blocking API calls to each other, services will publish "events" to a central message broker. Other services will then subscribe to these events and react accordingly. This decoupling is critical for building a resilient system that can handle traffic spikes and prevent a failure in one service from cascading and bringing down the entire system.16

3.2. High-Level Architecture Diagram

(A visual diagram would be presented here, illustrating the flow of data and events. The diagram would show external triggers (user actions, system events) feeding into the Event Ingestion Service. This service publishes to a central Message Bus (e.g., Kafka/Kinesis). The User Profile Service and Logic Engine are shown as consumers of this bus. The Logic Engine then sends a notification request to the Templating Service, which passes a formatted message to the Dispatch Gateway. The gateway communicates with external providers (OneSignal, Twilio). Finally, the Tracking Service receives webhooks from these providers and publishes interaction events back to the Message Bus, closing the feedback loop.)

3.3. Microservice Component Breakdown

The architecture comprises six core microservices, each with a distinct role:

  1. Event Ingestion Service: This service acts as the single, unified gateway for all incoming data that might trigger a notification. It is responsible for consuming a wide variety of events, such as user actions within the React Native app (e.g., profile_updated, event_viewed), backend system events (e.g., new_dining_event_created), or time-based triggers from a scheduler (e.g., send_daily_digest). Its primary function is to receive these raw events, validate their structure, and publish them in a standardized format onto a central, high-throughput message bus for consumption by other microservices.15
  2. User Profile & Preferences Service: This service is the system's source of truth for all user-related data. It maintains a comprehensive, 360-degree view of each user, encompassing not only their explicitly stated preferences (e.g., dietary restrictions, notification channel choices, do-not-disturb hours) but also their implicitly derived behavioral data (e.g., cuisines of events they've attended, average spend). It subscribes to the event bus to keep these profiles updated in real-time and exposes a secure API that the Logic Engine can query to retrieve the necessary data for personalization.18
  3. Logic Engine (The "Brain"): This is the central intelligence of the notification system. Its responsibility is to decide what message to send, to whom, when, and via which channel. It consumes key business events from the message bus, such as NewEventCreated. Upon receiving such an event, it queries the User Profile Service to fetch a cohort of potentially interested users. It then applies a set of business rules or, more powerfully, an AI-driven recommendation model (detailed in Section 4) to filter and score this cohort, producing a final list of recipients. Finally, it constructs a detailed "notification request" payload, specifying the target user, the content to be included, and the nudge strategy to employ.20
  4. Templating & Personalization Service: This service is responsible for transforming the abstract notification request from the Logic Engine into a concrete, channel-specific message. It maintains a repository of message templates (e.g., "New Event Push Notification v2," "Event Reminder SMS v1.1"). It receives the request, fetches the appropriate template, and dynamically populates it with personalized data, such as the user's name and the specific event details. This service can be enhanced to call a Generative AI model to create hyper-personalized, unique message copy on the fly.22
  5. Dispatch Gateway Service: This service acts as an abstraction layer between Cuculi's internal systems and the external communication providers (OneSignal for push, Twilio for SMS). It receives a fully formatted message from the Templating Service and is responsible for routing it to the correct provider's API. This centralizes all third-party integration logic, including handling API keys, managing provider-specific error codes, implementing retry policies, and enforcing rate limits, thus simplifying the other services.16
  6. Tracking & Monitoring Service: This service closes the feedback loop, which is essential for both analytics and model improvement. It exposes a public endpoint to receive status webhooks from OneSignal and Twilio (e.g., message_delivered, message_opened, message_clicked). It processes these webhooks, updates the status of the corresponding message in the notification history database, and publishes new "interaction events" (e.g., notification_clicked) back onto the central event bus. This real-time interaction data is invaluable for training the AI models and powering analytics dashboards.16

3.4. Database Schema Design (MongoDB)

The choice of a database schema in a NoSQL system like MongoDB is a critical architectural decision that directly impacts performance, scalability, and maintainability. A purely normalized (relational-style) schema would necessitate frequent, costly application-level joins, negating many of the benefits of a document database.25 Conversely, a heavily denormalized approach where all user data is embedded in a single document risks violating MongoDB's 16MB document size limit and leads to performance degradation when updating large, nested arrays.26

Therefore, the optimal strategy for Cuculi is a hybrid model. Frequently accessed and co-queried data, like a user's profile and their notification preferences, will be embedded within the main users document for fast reads. Data that can grow unboundedly, such as notification history, will be stored in a separate collection and linked via references. This approach provides the read performance of denormalization for common use cases while ensuring the scalability of normalization for high-volume data. To accommodate future evolution, the schemas will incorporate the Schema Versioning Pattern, allowing for non-disruptive updates over time.28

Table 1: MongoDB Schema Definitions for Cuculi Notification System

Collection

Field Name

Data Type

Description & Indexing

users

_id

ObjectId

Primary key.

username

String

Unique identifier for the user. Indexed.

email

String

User's email address. Indexed.

phone_number

String

User's phone number for SMS. Indexed.

profile

Object (Embedded)

Contains static user profile information.

profile.first_name

String

User's first name for personalization.

profile.dietary_preferences

Array of String

e.g., ["vegetarian", "gluten-free"]. Indexed for targeting.

profile.preferred_cuisines

Array of String

e.g., ["Italian", "Japanese"]. Indexed for targeting.

profile.avg_spend

Number

Average event cost preference.

behavioral_data

Object (Embedded)

Data for AI models, updated by the system.

behavioral_data.last_active_at

Date

Timestamp of the last user activity.

behavioral_data.events_rsvpd

Array of ObjectId

Reference to events the user has RSVP'd for.

behavioral_data.events_viewed

Array of ObjectId

Reference to events the user has viewed.

behavioral_data.user_vector

Array of Float

The user's embedding from the recommendation model.

notification_preferences

Object (Embedded)

User-configurable notification settings.29

notification_preferences.channels.push_enabled

Boolean

Default: true.

notification_preferences.channels.sms_enabled

Boolean

Default: true.

notification_preferences.do_not_disturb.enabled

Boolean

Default: false.

notification_preferences.do_not_disturb.start_time

String

"HH:MM" format, e.g., "22:00".

notification_preferences.do_not_disturb.end_time

String

"HH:MM" format, e.g., "08:00".

notification_preferences.frequency

String

Enum: "immediate", "daily_digest".

device_tokens

Array of String

OneSignal device tokens for push notifications.

schema_version

Number

Version number for the document schema.28

events

_id

ObjectId

Primary key.

title

String

Name of the dining event.

description

String

Detailed description of the event.

cuisine

String

Primary cuisine type. Indexed.

location

GeoJSON Point

For location-based recommendations. 2dsphere index.

event_date

Date

Date and time of the event. Indexed.

max_attendees

Number

Maximum capacity of the event.

current_attendees

Number

Current number of RSVPs.

event_vector

Array of Float

The event's embedding from the recommendation model.

notification_history

_id

ObjectId

Primary key.

user_id

ObjectId

Reference to the users collection. Indexed.

event_id

ObjectId

Reference to the events collection (if applicable).

template_id

String

Identifier for the message template used.

channel

String

Enum: "push", "sms".

provider

String

Enum: "OneSignal", "Twilio".

sent_at

Date

Timestamp when the notification was sent. Indexed.

status

String

Enum: "sent", "delivered", "failed", "opened", "clicked".

status_updated_at

Date

Timestamp of the last status update.

message_content

String

The final text of the message sent.

Section 4: Leveraging Artificial Intelligence for Hyper-Personalization

4.1. The Spectrum of AI in Notifications

Integrating Artificial Intelligence is not a monolithic task but rather a strategic journey along a spectrum of increasing sophistication and business value.31 For Cuculi, this journey can be visualized in four distinct stages, each building upon the last:

  1. Rule-Based Personalization: The starting point, using simple if-then logic to match users to events based on explicit preferences (e.g., IF user.profile.preferred_cuisines CONTAINS event.cuisine THEN notify).
  2. Predictive Personalization (Machine Learning): This stage moves beyond simple rules to predict user behavior. It involves training Machine Learning (ML) models on historical data to uncover complex patterns and recommend events that a user is likely to enjoy, even if they don't perfectly match their stated preferences.
  3. Generative Personalization (Generative AI): Here, AI is used not just to predict but to create. Large Language Models (LLMs) can generate novel, hyper-personalized notification content that is far more engaging than static templates.22
  4. Interactive Personalization (AI Agents): This is the most advanced stage, where AI transitions from a one-way messenger to a two-way conversational partner. AI Agents can understand user requests, reason about the best course of action, and perform tasks autonomously.32

4.2. Predictive Personalization: The Recommendation Engine

The core AI challenge for Cuculi is to accurately match the right user with the right dining event from an ever-changing catalog.

  • Chosen Method: Collaborative Filtering. This family of algorithms is exceptionally well-suited for a social platform like Cuculi. Collaborative filtering operates on the principle of "wisdom of the crowds": it recommends items to a user based on the tastes and behaviors of other, similar users.34 If User A and User B have both enjoyed similar events in the past, the system can infer that an event liked by User B might also appeal to User A. This approach excels at creating serendipitous discoveries—recommending events a user might love but would never have searched for explicitly—which is a key driver of engagement.34
  • How it Works for Cuculi:
  1. Data Input: The system's fuel is the user-event interaction matrix, a large dataset representing which users have interacted (e.g., viewed, RSVP'd, rated) with which events. This data is sourced directly from the users and notification_history collections.
  2. Model Training: An ML model, such as one using matrix factorization (e.g., Singular Value Decomposition - SVD) or a more advanced neural network, is trained on this interaction data.34 The model's goal is to learn a set of latent features for every user and every event, representing them as dense numerical vectors called "embeddings." These embeddings capture the nuanced "taste" of a user and the "character" of an event. The resulting vectors are stored in theusers.behavioral_data.user_vector and events.event_vector fields in MongoDB.
  3. Recommendation Generation: When a new event is created, the system can find the best users to notify by calculating the mathematical similarity (e.g., using cosine similarity or dot product) between the new event's vector and the vectors of all active users.35 The users with the highest similarity scores are the top candidates for a notification.
  • Addressing Inherent Challenges:
  • The Cold Start Problem: This is a well-known limitation of collaborative filtering. The system cannot make recommendations for new users (who have no interaction history) or new events (which have not yet been interacted with). To mitigate this, the system must implement a fallback strategy. Initially, it will rely on content-based filtering, matching new users to events based on their explicitly stated profile.preferred_cuisines and other profile data.34
  • Data Sparsity: In most real-world scenarios, the user-event matrix will be very sparse, as any given user will have only interacted with a tiny fraction of all available events. The chosen ML model must be robust to this sparsity.
  • The Modern Approach: LLM-Enhanced Recommendations:Traditional collaborative filtering is powerful, but modern techniques leveraging Large Language Models (LLMs) offer a significant leap in performance. Recent research demonstrates that LLMs can achieve superior recommendation quality by developing a deep semantic understanding of textual data, such as product descriptions and user reviews.38 Furthermore, specialized architectures can efficiently compress long, unstructured user histories into meaningful embedding vectors, which then act as highly effective "soft prompts" to guide the LLM's recommendations.40 For Cuculi, this means the long-term strategy should not be to build a classic collaborative filtering model in isolation. Instead, the goal should be ahybrid recommender system. This system would use a powerful LLM (like FlanT5 or a similar model) to generate the user and event embeddings. The model would be fed not just interaction data, but all available text: event titles and descriptions, user-provided dietary preferences, and in the future, user-generated reviews. This creates a much richer, more nuanced understanding of both users and events, leading to more accurate and compelling recommendations.

4.3. Generative Personalization: AI-Crafted Messages

Instead of relying on a limited set of rigid, static message templates, the system can use Generative AI to craft unique and dynamically personalized notification copy for each user.22

  • Implementation: The Templating & Personalization Service can be upgraded to include a call to a Generative AI model API (e.g., via Amazon Bedrock). The prompt sent to the model would be a carefully constructed package of information containing the user's profile, the event details, and the specific nudge type determined by the Logic Engine.
  • Example Prompt:JSON{ "user_context": { "name": "Alex", "preferences":, "last_attended_event": "Spicy Ramen Challenge" }, "event_context": { "title": "Beginner Sushi Making Class", "cuisine": "Japanese" }, "nudge_type": "Social Proof", "instruction": "Write a short, exciting, and friendly push notification to Alex about the event. Keep it under 150 characters."}
  • Potential AI Output: "Hey Alex! Ready for a new culinary adventure? Some of your fellow spicy food lovers are checking out a Beginner Sushi Making class this weekend. Looks like a perfect match!"

4.4. The Future: Interactive AI Agents

The ultimate evolution of this system is to move from one-way notifications to two-way, interactive conversations managed by an AI Agent.

  • Concept: An AI Agent is an autonomous software program that perceives its environment, reasons about a user's goals, creates a plan of action, and uses available tools (like APIs) to execute that plan.32 They are goal-based systems designed to complete complex tasks with minimal human intervention.41
  • Application to Cuculi: An AI Agent could become a personal dining concierge for each user. Instead of the system pushing a recommendation, the user could initiate a conversation.
  • User: (via chat interface in the app) "Anything interesting happening this Friday night?"
  • Cuculi Agent: (accessing event data and user profile) "Absolutely! There's a 'Vegan Italian Night' in your neighborhood and a 'Craft Beer Tasting' downtown. Based on your past RSVPs, the beer tasting seems right up your alley. It has a 4.8-star rating from other foodies. Would you like me to reserve a spot for you?"
  • Technical Feasibility: This is an advanced but achievable vision. It requires an LLM capable of reasoning and tool use (a pattern often implemented with frameworks like LangChain or directly with powerful models). The agent itself would be a new service that interacts with the existing microservice APIs (e.g., calling the event search API, the RSVP API, etc.) to fulfill the user's request. Platforms are emerging that even allow for the creation of visual, conversational agents that can listen and respond in real-time.42
  • Implementation Path: This is a long-term, post-launch initiative. The critical prerequisite is the creation of the robust, well-documented APIs for the core microservices in the "Smart System" (Option 2). The agent will then be built as a new consumer of these foundational APIs.

Section 5: Phased Implementation Roadmap & Technical Deep Dive

This section outlines three distinct implementation options, providing Cuculi with the flexibility to choose a path that aligns with its immediate resources and long-term ambitions. The primary recommendation is to pursue Option 2, the "Smart System," for which a detailed project plan is provided.

5.1. Option 1: The Quick-Start (Rule-Based System with n8n)

  • Goal: To launch a functional, personalized notification system in the shortest possible time, delivering immediate business value.
  • Workflow Automation Tool: n8n vs. Zapier:For a technology company building a core product feature, n8n is the superior choice over Zapier. Zapier excels at connecting a vast library of third-party SaaS applications through a simple, no-code interface, making it ideal for non-technical users and basic, linear automations.43 However, Cuculi's requirements are more complex, involving custom logic for matching users to events and direct interaction with a proprietary MongoDB database. n8n is designed for such scenarios. It provides a visual, node-based workflow editor but crucially allows for the injection of custom JavaScript or Python code directly into nodes. It offers more granular control over data manipulation and supports complex workflows with branching and merging. Furthermore, n8n can be self-hosted, which provides complete control over data privacy and can be significantly more cost-effective at scale compared to Zapier's task-based pricing.43 This makes n8n an excellent "bridge" technology that can serve as an MVP before migrating to a full microservices architecture.
  • Architecture:This approach consolidates the system's logic into a single, comprehensive n8n workflow.46
  1. Trigger: The workflow starts with a Cron node, configured to run on a schedule (e.g., every 30 minutes).
  2. Logic:
  • A MongoDB node executes a query to fetch any dining events created since the last run.
  • The workflow then iterates through each new event. For each event, another MongoDB node fetches all users.
  • A Code node runs custom JavaScript to loop through the list of users and apply simple matching rules (e.g., event.cuisine IN user.profile.preferred_cuisines).
  • For each user that matches, the workflow calls the OneSignal and Twilio nodes to dispatch the appropriate notification.
  • A final MongoDB node writes a record of the sent notification to the notification_history collection.
  • Timeline: 2-3 Weeks.

5.2. Option 2: The Smart System (Integrated AI/ML on AWS)

  • Goal: To build the full, scalable, and resilient microservices architecture described in Section 3, complete with an integrated AI/ML recommendation engine. This is the recommended primary path for achieving a sustainable competitive advantage.

Table 2: AWS Service Mapping for Cuculi's Smart Notification System

Microservice Component

Primary AWS Service

Justification & Alternatives

Event Ingestion

Amazon Kinesis Data Streams

Kinesis is purpose-built for high-throughput, real-time event streaming. It durably stores events and allows multiple independent consumer applications to process the same stream in parallel (e.g., the User Profile Service and the Logic Engine). At high volumes, it is more cost-effective than SQS. Its ability to retain data for up to a year also supports event replay for analytics or recovery.47

Alternative: Amazon SQS offers a simpler, fully-managed queue. It is a good choice for lower initial event volumes but lacks the multi-consumer replay capability of Kinesis.

User Profile & Preferences

AWS Lambda + MongoDB Atlas on AWS

Lambda provides a serverless, event-driven compute model that is perfect for processing events from Kinesis without managing servers. Since the backend is already MongoDB, using MongoDB Atlas hosted on AWS is the most direct and efficient path, providing a managed database service that integrates well with the AWS ecosystem and avoids a costly data migration.50

Alternative: Amazon DynamoDB for the user profile store if ultra-low, single-digit millisecond latency is the absolute top priority.

Logic Engine (AI/ML)

Amazon SageMaker

SageMaker is a fully managed platform that covers the entire machine learning lifecycle. It can be used to prepare data, train the collaborative filtering model, and deploy it as a scalable, real-time inference endpoint.51 The core of the Logic Engine will be an AWS Lambda function that orchestrates the process by invoking this SageMaker endpoint to get recommendations.52

Templating & Personalization

AWS Lambda

A lightweight Lambda function is sufficient for basic template string replacement. For the more advanced Generative AI capability, this Lambda can make a secure API call to Amazon Bedrock, which provides access to a variety of leading foundation models (like Claude, Llama, Titan) through a single API, simplifying integration.22

Dispatch Gateway

Amazon Simple Notification Service (SNS)

SNS is a managed pub/sub messaging service that natively supports dispatching notifications to multiple endpoints, including mobile push (via APNS for iOS and FCM for Android) and SMS.53 It is highly scalable, reliable, and cost-effective.

Alternative: Amazon Pinpoint offers more built-in marketing and analytics features like campaign management and A/B testing. However, it is more expensive than SNS for raw sends 56 and, critically, AWS has announced it will end support for the core Pinpoint service in October 2026.57 Given this deprecation,

SNS is the clear and future-proof choice for the dispatch layer.

Tracking & Monitoring

Amazon API Gateway + AWS Lambda

API Gateway is used to create a secure, public HTTPS endpoint that can receive delivery status webhooks from OneSignal and Twilio. The gateway is configured to trigger a Lambda function, which parses the webhook payload, updates the notification_history database, and publishes an interaction event back to the Kinesis stream.58

Database

MongoDB Atlas on AWS

This choice leverages the existing backend technology stack, ensuring developer familiarity and simplifying the architecture. Hosting on AWS allows for low-latency connections to the other services in the architecture and benefits from the scalability, security, and operational management of the Atlas platform.50

  • Detailed Implementation Plan (by Layer):The following project plan breaks down the construction of the Smart System into manageable phases, outlining the key tasks, milestones, and requirements for each stage.59

Table 3: Detailed Implementation Timeline with Milestones

Phase

Duration

Key Tasks

Milestone

Key Requirements

1. Foundation & Data Ingestion

3 Weeks

1. Finalize and implement MongoDB schemas (Table 1). 2. Set up MongoDB Atlas cluster on AWS. 3. Provision Amazon Kinesis Data Stream. 4. Instrument Cuculi backend services to publish NewEventCreated and UserUpdatedProfile events to Kinesis. 5. Configure basic CloudWatch alarms and logging for the new infrastructure.

Events are successfully captured from the backend and streamed into Kinesis in a standardized format.

Finalized data schemas for all events and entities. AWS account provisioned with appropriate IAM roles and permissions.

2. Logic & Execution Layers

4 Weeks

1. Develop User Profile Service (Lambda) to consume Kinesis events and update user documents in MongoDB. 2. Develop initial rule-based Logic Engine (Lambda) to match events and users. 3. Develop Templating Service (Lambda) with initial message templates. 4. Set up Amazon SNS, create topics, and configure platform applications for OneSignal (APNS/FCM) and SMS endpoints for Twilio. 5. Develop Dispatch Gateway (Lambda) to publish formatted messages to the correct SNS topic. 6. Develop Tracking Service (API Gateway + Lambda) to receive and process delivery status webhooks from providers.

A rule-based notification can be successfully triggered, sent, and its delivery status tracked end-to-end.

Active OneSignal and Twilio accounts with API credentials. A defined set of initial notification templates and nudge copy.

3. Integrating AI/ML

5 Weeks

1. Data Science: Extract historical user-event interaction data from existing logs and databases. Preprocess and clean the data for training. 2. SageMaker: Train and evaluate several collaborative filtering models (e.g., SVD, Factorization Machines, Neural Collaborative Filtering). 3. SageMaker: Deploy the champion model to a real-time inference endpoint. 4. Update the Logic Engine Lambda to replace the rule-based logic with a call to the SageMaker endpoint. 5. Implement the "cold start" fallback logic (reverting to content-based rules for new users/events). 6. Set up an A/B testing framework to compare the AI-driven recommendations against the rule-based control group.

The system can generate and send personalized event recommendations based on the trained ML model.

A sufficient volume of historical user interaction data to train a meaningful model. A dedicated data scientist or ML engineer resource.

4. Optimization & Rollout

2 Weeks

1. Continuously monitor system performance, latency, and cost using CloudWatch dashboards. 2. Monitor ML model performance (e.g., precision, recall) and schedule regular retraining. 3. Use a feature flagging system to gradually roll out the smart notification feature to user segments (e.g., 1%, 10%, 50%, 100%). 4. Analyze the impact on key business metrics (RSVP conversion rate, user engagement, churn). 5. Refine notification copy, timing, and nudge strategies based on A/B test results.

The smart notification feature is fully deployed to 100% of the user base, and its positive impact on conversion is verified.

An analytics dashboard to track KPIs. A feature flagging mechanism in the application backend.

Total Estimated Time

14 Weeks

5.3. Option 3: The Autonomous Future (AI Agent-Driven System)

  • Goal: To evolve the notification system into a conversational, interactive platform that can understand and act on user requests in natural language.
  • Architecture: This is an extension of the Smart System. It involves creating a new "Agent Service." This service will be powered by an LLM orchestration framework (like LangChain) or a managed conversational AI service (like Amazon Lex integrated with Amazon Bedrock). It will expose a new conversational API to the React Native front end. When a user interacts with it, the agent will reason about the request and make calls to the existing microservice APIs (e.g., searchEvents, createRSVP, updateUserPreferences) to fulfill its task.
  • Timeline: This is a strategic, long-term initiative. It should be considered after the Smart System has been operational and stable for at least 6-9 months, allowing time to build the robust APIs the agent will depend on.

Section 6: Conclusion & Next Steps

6.1. Summary of Recommendations

The analysis presented in this report leads to a clear set of strategic recommendations for Cuculi to achieve its goal of increasing user conversion. The development of a smart notification system, grounded in the principles of behavioral science and powered by artificial intelligence, represents a significant opportunity to enhance user engagement and drive core business metrics.

The primary recommendation is to pursue the "Smart System" (Option 2), building a scalable microservices architecture on AWS. This path provides the optimal balance between near-term capability and long-term strategic value. It establishes a resilient, extensible platform that can evolve with the business. While the "Quick-Start" n8n-based approach offers a faster MVP, it lacks the scalability and deep integration potential of the full microservices architecture.

Key to the success of this initiative will be the implementation of a hybrid push/SMS communication strategy. This conditional, multi-channel approach is critical for maximizing the visibility and impact of time-sensitive event notifications. Furthermore, moving beyond basic collaborative filtering to an LLM-enhanced recommendation engine will provide a significant competitive advantage, enabling a deeper, more nuanced level of personalization that will delight users and foster loyalty.

6.2. Path Forward

The proposed path forward is to proceed with the implementation of the "Smart System." The immediate next steps should be:

  1. Team Formation: Assemble a dedicated project team comprising a product manager, backend engineers, a data scientist/ML engineer, and a front-end (React Native) engineer to support integration.
  2. Architectural Review: Conduct a detailed architectural design review with the engineering leadership to finalize the specifics of the AWS service implementation and the microservice APIs.
  3. Initiate Phase 1: Commence work on Phase 1 of the project plan: "Foundation & Data Ingestion." This involves setting up the core AWS infrastructure and MongoDB schemas, which is the foundational work for all subsequent phases.

6.3. Final Thought

The implementation of this smart notification system should be viewed not as a one-off feature development, but as a foundational investment. It creates a powerful, data-driven engagement platform that will become a core asset for Cuculi. By understanding and intelligently acting upon user behavior, Cuculi can transform its relationship with its users from a simple transactional platform to a personalized and indispensable guide to social dining experiences. This will be a key driver of the company's future growth and success.

Works cited

  1. Nudge Theory in User Psychology - Number Analytics, accessed July 22, 2025, https://www.numberanalytics.com/blog/ultimate-guide-nudge-theory-user-psychology
  2. Harnessing the power of digital nudges to enhance user engagement and conversions, accessed July 22, 2025, https://twimbit.com/about/blogs/harnessing-the-power-of-digital-nudges-to-enhance-user-engagement-and-conversions
  3. Making Digital Nudging Applicable: The Digital Nudge Design Method, accessed July 22, 2025, https://aisel.aisnet.org/cgi/viewcontent.cgi?article=1072&context=icis2018
  4. Digital Nudging: Guiding Online User Choices through Interface Design - ResearchGate, accessed July 22, 2025, https://www.researchgate.net/publication/320419336_Digital_Nudging_Guiding_Online_User_Choices_through_Interface_Design
  5. Build an Efficient Customer Notification System | Fyno, accessed July 22, 2025, https://www.fyno.io/blog/customer-notification-system
  6. What Is Nudge Theory and How Can Nudges Improve Digital Experiences? - LAB, accessed July 22, 2025, https://lab.co.uk/news-and-insights/what-is-nudge-theory-and-how-can-nudges-improve-digital-experiences
  7. The Nudge Theory: Definition and Examples - Octet Design Studio, accessed July 22, 2025, https://octet.design/journal/nudge-theory/
  8. Push Notifications vs. SMS Messaging: What Should Marketers Use and When? - CleverTap, accessed July 22, 2025, https://clevertap.com/blog/push-notification-or-sms/
  9. Push Notifications vs SMS: What's the Best Channel for 2025? - MobiLoud, accessed July 22, 2025, https://www.mobiloud.com/blog/push-notifications-vs-sms
  10. Push Notifications vs. SMS: What You Need to Know Before Choosing the Right One, accessed July 22, 2025, https://textdrip.com/blog/push-notifications-vs-sms
  11. Push Notifications vs. SMS Messages: Which Should You Use? - MoEngage, accessed July 22, 2025, https://www.moengage.com/learn/choosing-between-push-notifications-vs-sms/
  12. Push Notifications vs SMS vs Email: Choosing the Best Channel for Your Business, accessed July 22, 2025, https://www.mobiloud.com/blog/push-notifications-vs-sms-vs-email
  13. Building a Notification Framework for Microservice-based Application | by Sohom Majumdar | Walmart Global Tech Blog | Medium, accessed July 22, 2025, https://medium.com/walmartglobaltech/building-a-notification-framework-for-microservice-based-application-6fe5ac9dfcee
  14. Design architecture of a notification system - Stack Overflow, accessed July 22, 2025, https://stackoverflow.com/questions/75017090/design-architecture-of-a-notification-system
  15. Build a Real-Time Notification System | by Anh Trần Tuấn | tuanhdotnet | Medium, accessed July 22, 2025, https://medium.com/tuanhdotnet/build-a-real-time-notification-system-ee0603d992c8
  16. Microservices Notification System Design - Vamshi Kesetty, accessed July 22, 2025, https://www.manning.com/liveprojectseries/microservices-notification-system-design-ser
  17. Highly Available Mass Notification System - PubNub, accessed July 22, 2025, https://www.pubnub.com/blog/scalable-mass-notification-system-design/
  18. Design Notification Services | System Design - GeeksforGeeks, accessed July 22, 2025, https://www.geeksforgeeks.org/system-design/design-notification-services-system-design/
  19. How to build a scalable notification service? A developer's guide - Fyno, accessed July 22, 2025, https://www.fyno.io/blog/how-to-build-a-scalable-notification-service-a-developers-guide-cm2tyu0lk00d8wixoiub6t3xz
  20. Building a Flexible and Scalable Notification System: Design and Implementation, accessed July 22, 2025, https://blog.devops.dev/building-a-flexible-and-scalable-notification-system-design-and-implementation-eef601f22518
  21. Designing a Notification System - Design Gurus, accessed July 22, 2025, https://www.designgurus.io/course-play/grokking-system-design-interview-ii/doc/designing-a-notification-system
  22. Deep-Dive into AI/ML to Enhance Customer Engagement - WebEngage, accessed July 22, 2025, https://webengage.com/blog/ai-ml-to-enhance-customer-engagement/
  23. Notifications System Design: How we integrated it ... - Bits and Pieces, accessed July 22, 2025, https://blog.bitsrc.io/notifications-system-design-how-we-integrated-it-into-our-infrastructure-f93f279c18a0
  24. How Does a Typical Push Notification System Work? - ByteByteGo, accessed July 22, 2025, https://bytebytego.com/guides/how-does-a-typical-push-notification-system-work/
  25. Data Modeling - Database Manual - MongoDB Docs, accessed July 22, 2025, https://www.mongodb.com/docs/manual/data-modeling/
  26. Mongoose / MongoDB User notifications scheme suggestions - Stack Overflow, accessed July 22, 2025, https://stackoverflow.com/questions/9965533/mongoose-mongodb-user-notifications-scheme-suggestions
  27. 3 Practical MongoDB Schema Examples (for 2024 & Beyond) - Dragonfly, accessed July 22, 2025, https://www.dragonflydb.io/databases/schema/mongodb
  28. Maintain Different Schema Versions - Database Manual - MongoDB Docs, accessed July 22, 2025, https://www.mongodb.com/docs/manual/data-modeling/design-patterns/data-versioning/schema-versioning/
  29. How to Build MongoDB User Profiles - LabEx, accessed July 22, 2025, https://labex.io/tutorials/mongodb-build-mongodb-user-profiles-422077
  30. Configure Alert Settings - Atlas - MongoDB Docs, accessed July 22, 2025, https://www.mongodb.com/docs/atlas/configure-alerts/
  31. How to use machine learning to keep users engaged | EU-Startups, accessed July 22, 2025, https://www.eu-startups.com/2025/03/how-to-use-machine-learning-to-keep-users-engaged/
  32. What are AI agents? Definition, examples, and types | Google Cloud, accessed July 22, 2025, https://cloud.google.com/discover/what-are-ai-agents
  33. What Are AI Agents? | IBM, accessed July 22, 2025, https://www.ibm.com/think/topics/ai-agents
  34. Collaborative filtering: How to build a recommender system - Redis, accessed July 22, 2025, https://redis.io/blog/collaborative-filtering-how-to-build-a-recommender-system/
  35. What is collaborative filtering? - IBM, accessed July 22, 2025, https://www.ibm.com/think/topics/collaborative-filtering
  36. Collaborative Filtering: Your Guide to Smarter Recommendations - DataCamp, accessed July 22, 2025, https://www.datacamp.com/tutorial/collaborative-filtering
  37. Collaborative Future Event Recommendation | MIT, accessed July 22, 2025, https://rvsn.csail.mit.edu/location/Minkov_collaborative_recommendation.pdf
  38. [2403.19345] Intelligent Classification and Personalized Recommendation of E-commerce Products Based on Machine Learning - arXiv, accessed July 22, 2025, https://arxiv.org/abs/2403.19345
  39. [2410.12829] Leveraging Large Language Models to Enhance Personalized Recommendations in E-commerce - arXiv, accessed July 22, 2025, https://arxiv.org/abs/2410.12829
  40. User Embedding Model for Personalized Language Prompting, accessed July 22, 2025, https://arxiv.org/abs/2401.04858
  41. What are AI agents? How they work and how to use them - Zapier, accessed July 22, 2025, https://zapier.com/blog/ai-agent/
  42. AI Agents: Create an Interactive Visual Agent - D-ID, accessed July 22, 2025, https://www.d-id.com/ai-agents/
  43. n8n vs Zapier: Comparison of AI Workflow Automation Tools - PromptLayer, accessed July 22, 2025, https://blog.promptlayer.com/n8n-vs-zapier/
  44. Zapier vs n8n (and why Shopstory is better), accessed July 22, 2025, https://www.shopstory.ai/en/blog/zapier-vs-n8n-which-automation-tool-is-better-for-ecommerce-and-performance-marketing
  45. n8n vs. Zapier: Feature, pricing, and usability comparison - Hostinger, accessed July 22, 2025, https://www.hostinger.com/tutorials/n8n-vs-zapier
  46. Food Menu Update Notifier | n8n workflow template, accessed July 22, 2025, https://n8n.io/workflows/5877-food-menu-update-notifier/
  47. Amazon Kinesis Data Streams - AWS, accessed July 22, 2025, https://aws.amazon.com/kinesis/data-streams/
  48. Use Amazon Kinesis Data Streams to deliver real-time data to ... - AWS, accessed July 22, 2025, https://aws.amazon.com/blogs/big-data/use-amazon-kinesis-data-streams-to-deliver-real-time-data-to-amazon-opensearch-service-domains-with-amazon-opensearch-ingestion/
  49. Amazon Kinesis vs. SQS: Differences & Comparison · AutoMQ ..., accessed July 22, 2025, https://github.com/AutoMQ/automq/wiki/Amazon-Kinesis-vs.-SQS:-Differences-&-Comparison
  50. Scalable Notification System Design for 50 Million Users (Database Design), accessed July 22, 2025, https://dev.to/ndohjapan/scalable-notification-system-design-for-50-million-users-database-design-4cl
  51. aws-samples/amazon-sagemaker-custom-recommender-system - GitHub, accessed July 22, 2025, https://github.com/aws-samples/amazon-sagemaker-custom-recommender-system
  52. NotificationConfiguration - Amazon SageMaker - AWS Documentation, accessed July 22, 2025, https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_NotificationConfiguration.html
  53. Amazon SNS in 30 Minutes | Simple Notification Service Explained - .NET on AWS, accessed July 22, 2025, https://www.youtube.com/watch?v=TJpWHFOTefw&pp=0gcJCf0Ao7VqN5tD
  54. Amazon Simple Notification Service (SNS) - AWS, accessed July 22, 2025, https://aws.amazon.com/sns/
  55. What is Amazon SNS? - Amazon Simple Notification Service - AWS Documentation, accessed July 22, 2025, https://docs.aws.amazon.com/sns/latest/dg/welcome.html
  56. Why is sending push notifications twice as expensive using Pinpoint vs using SNS : r/aws, accessed July 22, 2025, https://www.reddit.com/r/aws/comments/1al5ebh/why_is_sending_push_notifications_twice_as/
  57. Amazon Pinpoint – Amazon Web Services, accessed July 22, 2025, https://aws.amazon.com/pinpoint/
  58. Monitor your Lambda function and get notified with AWS Chatbot, accessed July 22, 2025, https://aws.amazon.com/blogs/mt/monitor-your-lambda-function-and-get-notified-with-aws-chatbot/
  59. How to Create an Implementation Plan: Tips + Template - Qwilr, accessed July 22, 2025, https://qwilr.com/blog/how-to-create-an-implementation-plan/
  60. How to Create an Implementation Plan: Tips + Template - Qwilr, accessed July 22, 2025, https://www.qwilr.com/blog/how-to-create-an-implementation-plan/