evernote-reference-architecture

name	evernote-reference-architecture
description	Reference architecture for Evernote integrations. Use when designing system architecture, planning integrations, or building scalable Evernote applications. Trigger with phrases like "evernote architecture", "design evernote system", "evernote integration pattern", "evernote scale".
allowed-tools	Read, Write, Edit, Grep
version	1.13.0
license	MIT
author	Jeremy Longshore <[e-mail]>
tags	["saas","evernote","scaling"]
compatibility	Designed for Claude Code, also compatible with Codex and OpenClaw

Evernote Reference Architecture

Overview

Production-ready architecture patterns for building scalable, maintainable Evernote integrations. Covers service layer design, caching strategy, sync architecture, and deployment topology.

Prerequisites

• Understanding of microservices or modular monolith architecture
• Cloud platform familiarity (AWS, GCP, or Azure)
• Knowledge of message queues and caching

Instructions

Architecture Layers

Client Layer    [Web App / Mobile / CLI]
                        |
API Layer       [Express/Fastify REST API]
                        |
Service Layer   [NoteService | SearchService | SyncService]
                        |
Integration     [EvernoteClient (rate-limited, instrumented)]
                        |
Infrastructure  [Redis Cache | PostgreSQL | Message Queue]

Service Layer Design

Separate concerns into focused services:

• NoteService: CRUD operations, ENML formatting, tag management
• SearchService: Query building, pagination, result enrichment
• SyncService: Webhook handling, incremental sync, conflict resolution
• AuthService: OAuth flow, token storage, refresh logic

// services/index.js - Service registry
class ServiceRegistry {
  constructor(noteStore, cache, db) {
    this.notes = new NoteService(noteStore);
    this.search = new SearchService(noteStore, cache);
    this.sync = new SyncService(noteStore, db);
  }
}

Caching Strategy

Cache at two levels: in-memory LRU for hot data (note metadata, user info) and Redis for shared state (notebook lists, tag lists, sync checkpoints). Invalidate on webhook notification.

Sync Architecture

Use webhooks as the primary change notification channel. Fall back to polling when webhooks are unavailable. Process changes through a message queue for reliability and retry. Store sync state (USN) in the database for crash recovery.