Groq Reference Architecture
Overview
Production architecture for applications built on Groq's LPU inference API. It
covers four concerns that every serious Groq integration needs: routing requests
to the right model by latency/capability/cost, a middleware band (cache, metrics,
retry), a multi-provider fallback chain, and a streaming pipeline. The service
layer built here is reusable across a chat UI, an API backend, a batch processor,
or an agent.
The full layer diagram and how the pieces interact lives in
references/architecture.md; the complete,
copy-ready TypeScript for every layer is in
references/implementation.md.
Prerequisites
- Groq API key — create one at console.groq.com
and export it as
GROQ_API_KEY. The Groq SDK reads it from the environment;
the client is constructed as new Groq({ apiKey: process.env.GROQ_API_KEY }).
Never hardcode the key.
- Runtime: Node.js 18+ (for
performance.now() and native fetch).
- Packages:
groq-sdk and lru-cache (npm install groq-sdk lru-cache).
- Optional backup provider: an OpenAI-compatible key if you extend the
fallback chain beyond Groq's own models.
Instructions
Build the service layer in five ordered steps. Each step is one file under
src/groq/. The router depends on the registry; the middleware and fallback
depend on the client; the streaming pipeline stands alone. Full source for every
step (verbatim) is in references/implementation.md.
Model Registry (models.ts) — declare a ModelSpec for each model with
its tier, context window, speed, cost, and capabilities. Skeleton:
export const MODELS: Record<string, ModelSpec> = {
"llama-3.1-8b-instant": { tier: "speed", /* fast, cheap */ },
"llama-3.3-70b-versatile": { tier: "quality", /* tools + JSON */ },
"meta-llama/llama-4-scout-17b-16e-instruct": { tier: "vision" },
"whisper-large-v3-turbo": { tier: "audio" },
};
Model Router (router.ts) — selectModel(req) maps requirements
(maxLatencyMs, needsVision, needsTools, costSensitive) to the cheapest
model that satisfies them. Callers pass requirements, never hardcoded ids.
Middleware (middleware.ts) — completionWithMiddleware() wraps each call
with an LRU cache (deterministic requests only, temperature === 0), latency +
token metrics, and a pluggable metrics sink.
Fallback Chain (fallback.ts) — completionWithFallback() tries the
primary model, drops to a model in a different rate-limit pool on 429/5xx, then
returns a graceful-degradation payload instead of throwing.
Streaming Pipeline (streaming.ts) — streamCompletion() is an async
generator yielding { type: "token" | "done" | "error" } for real-time SSE UIs.
When applying this to an existing repo, Read the current src/ layout and
Grep for direct groq.chat.completions.create calls to find code that should
route through the middleware and fallback wrappers instead.
Integration Patterns
| Pattern |
When to Use |
Groq Feature |
| Direct completion |
Simple request/response |
chat.completions.create |
| Streaming SSE |
Real-time chat UI |
stream: true |
| Tool calling |
Agent with function execution |
tools parameter |
| JSON extraction |
Structured data from text |
response_format: json_object |
| Batch processing |
High-volume document processing |
Queue + rate limiting |
| Audio transcription |
Voice input |
audio.transcriptions.create |
| Vision analysis |
Image understanding |
Llama 4 Scout/Maverick |
Output
Applying this skill produces a src/groq/ service layer with six files
(client.ts, models.ts, router.ts, middleware.ts, fallback.ts,
streaming.ts) plus the service and API layers that consume it. At runtime you get:
- Routed completions —
selectModel() returns a ModelSpec; callers never
hardcode a model id, so cost/latency policy lives in one place.
- Cached deterministic responses — repeated
temperature: 0 calls return from
the LRU cache instead of re-billing the API.
- Resilient calls —
completionWithFallback() returns a valid completion shape
even when Groq is rate-limited, never surfacing a raw 429 to the user.
- Streamed tokens —
streamCompletion() yields { type, content } events for
SSE, with a terminal done or error event.
- Metrics — every call emits
{ model, latencyMs, tokens, cached } to your
metrics sink (Prometheus, Datadog, or console.log by default).
Error Handling
| Issue |
Cause |
Solution |
| 429 on primary model |
RPM/TPM exceeded |
Fall back to different model |
| High latency |
Wrong model tier |
Route to 8b-instant for latency-critical paths |
| Context overflow |
Input > 128K tokens |
Truncate or chunk input |
| Vision errors |
Wrong model for images |
Use Llama 4 Scout full model path |
GROQ_API_KEY undefined |
Env var not exported |
Export the key before starting the process |
Examples
A latency-critical chat turn routes to the speed tier and returns one completion:
const model = selectModel({ maxLatencyMs: 80, costSensitive: true });
// → llama-3.1-8b-instant
const res = await completionWithMiddleware(groq, model.id, messages);
Streaming a UI consumes the async generator token-by-token:
for await (const event of streamCompletion(groq, messages)) {
if (event.type === "token") process.stdout.write(event.content!);
}
Four fully worked examples — latency-critical, quality-with-fallback, streaming,
and vision routing — are in references/examples.md.
Resources
Next Steps
For multi-environment deployment, see the groq-multi-env-setup skill, which
extends this service layer with per-environment configuration and secrets handling.
1---2name: groq-reference-architecture3description: Implement Groq reference architecture with model routing, streaming pipelines, and fallbacks. Use when designing new Groq integrations, reviewing project structure, or establishing architecture standards for Groq applications. Trigger with phrases like "groq architecture", "groq best practices", "groq project structure", "how to organize groq", "groq design".4license: MIT5---6# Groq Reference Architecture
7
8## Overview
9
10Production architecture for applications built on Groq's LPU inference API. It
11covers four concerns that every serious Groq integration needs: routing requests
12to the right model by latency/capability/cost, a middleware band (cache, metrics,
13retry), a multi-provider fallback chain, and a streaming pipeline. The service
14layer built here is reusable across a chat UI, an API backend, a batch processor,
15or an agent.
16
17The full layer diagram and how the pieces interact lives in
18[references/architecture.md](references/architecture.md); the complete,
19copy-ready TypeScript for every layer is in
20[references/implementation.md](references/implementation.md).
21
22## Prerequisites
23
24- **Groq API key** — create one at [console.groq.com](https://console.groq.com)
25 and export it as `GROQ_API_KEY`. The Groq SDK reads it from the environment;
26 the client is constructed as `new Groq({ apiKey: process.env.GROQ_API_KEY })`.
27 Never hardcode the key.
28- **Runtime**: Node.js 18+ (for `performance.now()` and native `fetch`).
29- **Packages**: `groq-sdk` and `lru-cache` (`npm install groq-sdk lru-cache`).
30- **Optional backup provider**: an OpenAI-compatible key if you extend the
31 fallback chain beyond Groq's own models.
32
33## Instructions
34
35Build the service layer in five ordered steps. Each step is one file under
36`src/groq/`. The router depends on the registry; the middleware and fallback
37depend on the client; the streaming pipeline stands alone. Full source for every
38step (verbatim) is in [references/implementation.md](references/implementation.md).
39
401. **Model Registry** (`models.ts`) — declare a `ModelSpec` for each model with
41 its tier, context window, speed, cost, and capabilities. Skeleton:
42
43 ```typescript
44 export const MODELS: Record<string, ModelSpec> = {
45 "llama-3.1-8b-instant": { tier: "speed", /* fast, cheap */ },
46 "llama-3.3-70b-versatile": { tier: "quality", /* tools + JSON */ },
47 "meta-llama/llama-4-scout-17b-16e-instruct": { tier: "vision" },
48 "whisper-large-v3-turbo": { tier: "audio" },
49 };
50 ```
51
522. **Model Router** (`router.ts`) — `selectModel(req)` maps requirements
53 (`maxLatencyMs`, `needsVision`, `needsTools`, `costSensitive`) to the cheapest
54 model that satisfies them. Callers pass requirements, never hardcoded ids.
553. **Middleware** (`middleware.ts`) — `completionWithMiddleware()` wraps each call
56 with an LRU cache (deterministic requests only, `temperature === 0`), latency +
57 token metrics, and a pluggable metrics sink.
584. **Fallback Chain** (`fallback.ts`) — `completionWithFallback()` tries the
59 primary model, drops to a model in a different rate-limit pool on 429/5xx, then
60 returns a graceful-degradation payload instead of throwing.
615. **Streaming Pipeline** (`streaming.ts`) — `streamCompletion()` is an async
62 generator yielding `{ type: "token" | "done" | "error" }` for real-time SSE UIs.
63
64When applying this to an existing repo, `Read` the current `src/` layout and
65`Grep` for direct `groq.chat.completions.create` calls to find code that should
66route through the middleware and fallback wrappers instead.
67
68## Integration Patterns
69
70| Pattern | When to Use | Groq Feature |
71|---------|-------------|-------------|
72| Direct completion | Simple request/response | `chat.completions.create` |
73| Streaming SSE | Real-time chat UI | `stream: true` |
74| Tool calling | Agent with function execution | `tools` parameter |
75| JSON extraction | Structured data from text | `response_format: json_object` |
76| Batch processing | High-volume document processing | Queue + rate limiting |
77| Audio transcription | Voice input | `audio.transcriptions.create` |
78| Vision analysis | Image understanding | Llama 4 Scout/Maverick |
79
80## Output
81
82Applying this skill produces a `src/groq/` service layer with six files
83(`client.ts`, `models.ts`, `router.ts`, `middleware.ts`, `fallback.ts`,
84`streaming.ts`) plus the service and API layers that consume it. At runtime you get:
85
86- **Routed completions** — `selectModel()` returns a `ModelSpec`; callers never
87 hardcode a model id, so cost/latency policy lives in one place.
88- **Cached deterministic responses** — repeated `temperature: 0` calls return from
89 the LRU cache instead of re-billing the API.
90- **Resilient calls** — `completionWithFallback()` returns a valid completion shape
91 even when Groq is rate-limited, never surfacing a raw 429 to the user.
92- **Streamed tokens** — `streamCompletion()` yields `{ type, content }` events for
93 SSE, with a terminal `done` or `error` event.
94- **Metrics** — every call emits `{ model, latencyMs, tokens, cached }` to your
95 metrics sink (Prometheus, Datadog, or `console.log` by default).
96
97## Error Handling
98
99| Issue | Cause | Solution |
100|-------|-------|----------|
101| 429 on primary model | RPM/TPM exceeded | Fall back to different model |
102| High latency | Wrong model tier | Route to `8b-instant` for latency-critical paths |
103| Context overflow | Input > 128K tokens | Truncate or chunk input |
104| Vision errors | Wrong model for images | Use Llama 4 Scout full model path |
105| `GROQ_API_KEY` undefined | Env var not exported | Export the key before starting the process |
106
107## Examples
108
109A latency-critical chat turn routes to the speed tier and returns one completion:
110
111```typescript
112const model = selectModel({ maxLatencyMs: 80, costSensitive: true });
113// → llama-3.1-8b-instant
114const res = await completionWithMiddleware(groq, model.id, messages);
115```
116
117Streaming a UI consumes the async generator token-by-token:
118
119```typescript
120for await (const event of streamCompletion(groq, messages)) {
121 if (event.type === "token") process.stdout.write(event.content!);
122}
123```
124
125Four fully worked examples — latency-critical, quality-with-fallback, streaming,
126and vision routing — are in [references/examples.md](references/examples.md).
127
128## Resources
129
130- [Groq API Documentation](https://console.groq.com/docs)
131- [Groq Models](https://console.groq.com/docs/models)
132- [Groq Rate Limits](https://console.groq.com/docs/rate-limits)
133- [Groq Pricing](https://groq.com/pricing)
134
135## Next Steps
136
137For multi-environment deployment, see the `groq-multi-env-setup` skill, which
138extends this service layer with per-environment configuration and secrets handling.