Choose and implement Exa validated architecture blueprints for different scales. Use when designing new Exa integrations, choosing between monolith/service/microservice architectures, or planning migration paths for Exa applications. Trigger with phrases like "exa architecture", "exa blueprint", "how to structure exa", "exa project layout", "exa microservice".
Installation
Details
Usage
After installing, this skill will be available to your AI coding assistant.
Verify installation:
skills listSkill Instructions
name: exa-architecture-variants description: | Choose and implement Exa validated architecture blueprints for different scales. Use when designing new Exa integrations, choosing between monolith/service/microservice architectures, or planning migration paths for Exa applications. Trigger with phrases like "exa architecture", "exa blueprint", "how to structure exa", "exa project layout", "exa microservice". allowed-tools: Read, Grep version: 1.0.0 license: MIT author: Jeremy Longshore jeremy@intentsolutions.io
Exa Architecture Variants
Overview
Three validated architecture blueprints for Exa integrations.
Prerequisites
- Understanding of team size and DAU requirements
- Knowledge of deployment infrastructure
- Clear SLA requirements
- Growth projections available
Variant A: Monolith (Simple)
Best for: MVPs, small teams, < 10K daily active users
my-app/
├── src/
│ ├── exa/
│ │ ├── client.ts # Singleton client
│ │ ├── types.ts # Types
│ │ └── middleware.ts # Express middleware
│ ├── routes/
│ │ └── api/
│ │ └── exa.ts # API routes
│ └── index.ts
├── tests/
│ └── exa.test.ts
└── package.json
Key Characteristics
- Single deployment unit
- Synchronous Exa calls in request path
- In-memory caching
- Simple error handling
Code Pattern
// Direct integration in route handler
app.post('/api/create', async (req, res) => {
try {
const result = await exaClient.create(req.body);
res.json(result);
} catch (error) {
res.status(500).json({ error: error.message });
}
});
Variant B: Service Layer (Moderate)
Best for: Growing startups, 10K-100K DAU, multiple integrations
my-app/
├── src/
│ ├── services/
│ │ ├── exa/
│ │ │ ├── client.ts # Client wrapper
│ │ │ ├── service.ts # Business logic
│ │ │ ├── repository.ts # Data access
│ │ │ └── types.ts
│ │ └── index.ts # Service exports
│ ├── controllers/
│ │ └── exa.ts
│ ├── routes/
│ ├── middleware/
│ ├── queue/
│ │ └── exa-processor.ts # Async processing
│ └── index.ts
├── config/
│ └── exa/
└── package.json
Key Characteristics
- Separation of concerns
- Background job processing
- Redis caching
- Circuit breaker pattern
- Structured error handling
Code Pattern
// Service layer abstraction
class ExaService {
constructor(
private client: ExaClient,
private cache: CacheService,
private queue: QueueService
) {}
async createResource(data: CreateInput): Promise<Resource> {
// Business logic before API call
const validated = this.validate(data);
// Check cache
const cached = await this.cache.get(cacheKey);
if (cached) return cached;
// API call with retry
const result = await this.withRetry(() =>
this.client.create(validated)
);
// Cache result
await this.cache.set(cacheKey, result, 300);
// Async follow-up
await this.queue.enqueue('exa.post-create', result);
return result;
}
}
Variant C: Microservice (Complex)
Best for: Enterprise, 100K+ DAU, strict SLAs
exa-service/ # Dedicated microservice
├── src/
│ ├── api/
│ │ ├── grpc/
│ │ │ └── exa.proto
│ │ └── rest/
│ │ └── routes.ts
│ ├── domain/
│ │ ├── entities/
│ │ ├── events/
│ │ └── services/
│ ├── infrastructure/
│ │ ├── exa/
│ │ │ ├── client.ts
│ │ │ ├── mapper.ts
│ │ │ └── circuit-breaker.ts
│ │ ├── cache/
│ │ ├── queue/
│ │ └── database/
│ └── index.ts
├── config/
├── k8s/
│ ├── deployment.yaml
│ ├── service.yaml
│ └── hpa.yaml
└── package.json
other-services/
├── order-service/ # Calls exa-service
├── payment-service/
└── notification-service/
Key Characteristics
- Dedicated Exa microservice
- gRPC for internal communication
- Event-driven architecture
- Database per service
- Kubernetes autoscaling
- Distributed tracing
- Circuit breaker per service
Code Pattern
// Event-driven with domain isolation
class ExaAggregate {
private events: DomainEvent[] = [];
process(command: ExaCommand): void {
// Domain logic
const result = this.execute(command);
// Emit domain event
this.events.push(new ExaProcessedEvent(result));
}
getUncommittedEvents(): DomainEvent[] {
return [...this.events];
}
}
// Event handler
@EventHandler(ExaProcessedEvent)
class ExaEventHandler {
async handle(event: ExaProcessedEvent): Promise<void> {
// Saga orchestration
await this.sagaOrchestrator.continue(event);
}
}
Decision Matrix
| Factor | Monolith | Service Layer | Microservice |
|---|---|---|---|
| Team Size | 1-5 | 5-20 | 20+ |
| DAU | < 10K | 10K-100K | 100K+ |
| Deployment Frequency | Weekly | Daily | Continuous |
| Failure Isolation | None | Partial | Full |
| Operational Complexity | Low | Medium | High |
| Time to Market | Fastest | Moderate | Slowest |
Migration Path
Monolith → Service Layer:
1. Extract Exa code to service/
2. Add caching layer
3. Add background processing
Service Layer → Microservice:
1. Create dedicated exa-service repo
2. Define gRPC contract
3. Add event bus
4. Deploy to Kubernetes
5. Migrate traffic gradually
Instructions
Step 1: Assess Requirements
Use the decision matrix to identify appropriate variant.
Step 2: Choose Architecture
Select Monolith, Service Layer, or Microservice based on needs.
Step 3: Implement Structure
Set up project layout following the chosen blueprint.
Step 4: Plan Migration Path
Document upgrade path for future scaling.
Output
- Architecture variant selected
- Project structure implemented
- Migration path documented
- Appropriate patterns applied
Error Handling
| Issue | Cause | Solution |
|---|---|---|
| Over-engineering | Wrong variant choice | Start simpler |
| Performance issues | Wrong layer | Add caching/async |
| Team friction | Complex architecture | Simplify or train |
| Deployment complexity | Microservice overhead | Consider service layer |
Examples
Quick Variant Check
# Count team size and DAU to select variant
echo "Team: $(git log --format='%ae' | sort -u | wc -l) developers"
echo "DAU: Check analytics dashboard"
Resources
Next Steps
For common anti-patterns, see exa-known-pitfalls.
More by jeremylongshore
View allRabbitmq Queue Setup - Auto-activating skill for Backend Development. Triggers on: rabbitmq queue setup, rabbitmq queue setup Part of the Backend Development skill category.
evaluating-machine-learning-models: This skill allows Claude to evaluate machine learning models using a comprehensive suite of metrics. It should be used when the user requests model performance analysis, validation, or testing. Claude can use this skill to assess model accuracy, precision, recall, F1-score, and other relevant metrics. Trigger this skill when the user mentions "evaluate model", "model performance", "testing metrics", "validation results", or requests a comprehensive "model evaluation".
building-neural-networks: This skill allows Claude to construct and configure neural network architectures using the neural-network-builder plugin. It should be used when the user requests the creation of a new neural network, modification of an existing one, or assistance with defining the layers, parameters, and training process. The skill is triggered by requests involving terms like "build a neural network," "define network architecture," "configure layers," or specific mentions of neural network types (e.g., "CNN," "RNN," "transformer").
Oauth Callback Handler - Auto-activating skill for API Integration. Triggers on: oauth callback handler, oauth callback handler Part of the API Integration skill category.
