1 Minute Signal Architecture: How the AI Content Intelligence Platform Works

1 Minute Signal has two very different jobs.

The first is a familiar web-product job: serve a fast, reliable experience where people can browse a feed, open an article, sign in, manage a subscription, and read from a phone or computer.

The second is an asynchronous intelligence job: monitor external sources, acquire transcripts, run multi-stage AI workflows, validate structured output, assign tags and scores, conduct broader research, and publish finished content.

Trying to make one runtime handle both jobs would have been simpler on a diagram but much worse in production. A reader should not wait for an LLM response. A stalled transcript provider should not slow the home page. A thirty-minute research task should not compete for resources with an authentication request.

The core architecture of this platform is built around that separation.

1 Minute Signal runs from an Nx monorepo and uses three main services on Google Cloud Run:

A Next.js web service for the public product, authenticated web experience, staff tools, and web commerce
A NestJS API service for contract-driven client APIs, mobile authentication, Google Play billing, analytics ingestion, and device capabilities
A NestJS worker service for monitoring, ingestion, AI pipelines, scheduled jobs, research generation, distribution, and other long-running work

PostgreSQL holds operational truth. Cloud Tasks and Cloud Scheduler coordinate durable background work. Pub/Sub and BigQuery handle product analytics. External AI and content services sit behind explicit adapters. By the time a reader opens a signal, the expensive intelligence work has already happened.

This is not an architecture designed for hypothetical massive scale. It is designed for the product I actually operate: a public, production-grade AI system run by one person, where cost and simplicity matter but user trust, security, and reliability still have to be real.

The system at a glance

Solid arrows are work the product depends on. Dashed arrows are analytics events and traces.

The most important boundaries are more useful than the vendor names:

Readers use finished data. Models do not generate the public feed or a signal page while someone waits.
Long-running work belongs to the worker. Monitoring channel feeds, transcript processing, AI workflows, research, and push delivery stay off the reader-facing path.
PostgreSQL is the operational source of truth. BigQuery is for learning from product behavior, not deciding whether a user has access or whether content exists.
Clients do not grant themselves access. Billing providers trigger server-side verification before a shared entitlement ledger changes.
Optional telemetry fails open. An analytics or AI-tracing problem should not prevent the core product action from succeeding.

The constraints that shaped the architecture

Architecture decisions make more sense when the constraints are visible.

A public product needs a fast, indexable web surface

1 Minute Signal is both a product and a publication. Public signal and research pages need predictable URLs, server-rendered content, useful metadata, and good performance for readers and search systems. The web application cannot behave like a thin loading screen waiting for a collection of backend calls.

Next.js gives the product one place for public pages, authenticated account experiences, server rendering, route handlers, and staff interfaces. It can read finalized feed data directly from PostgreSQL where that keeps the request path simple.

AI work has a very different execution profile

A normal product request should complete quickly. A transcript and AI pipeline may involve several external providers, multiple model calls, structured-output validation, retry delays, and database writes. Research workflows can run much longer.

Those jobs need different timeouts, concurrency, retry rules, logging, and scaling behavior. They also fail differently. A model timeout is expected operational noise. A home-page timeout is a user-facing incident.

The system has more than one client

The web experience is the primary product surface, but the Android application needs native authentication, push notifications, and Google Play Billing. Those are better handled through explicit API contracts than through browser-specific routes or direct database access.

I operate it alone

Every service, queue, dashboard, deployment step, and alert becomes part of one person's operational workload. That strongly favors managed cloud services, shared packages, visible limits, and a small number of deployable units.

The system needs enough separation to isolate real failure modes, but not so much separation that operating the architecture becomes the product.

Cost is part of product design

Cloud SQL size, Cloud Run instance settings, model selection, trace sampling, hosted checkout, and the WebView-first Android approach all reflect cost constraints. Saving money is not the same as choosing the cheapest possible implementation. The objective is to spend where reliability or product value justifies it and remain deliberately lean elsewhere.

Three services, not a monolith and not a microservice estate

The web, API, and worker split is the smallest separation I found that matched the physical behavior of the product.

Service	Primary responsibilities	Why it is separate
Web	Public feed and articles, NextAuth sessions, account and upgrade experiences, staff UI, Lemon Squeezy checkout and webhooks	Optimized for page performance, rendering, search visibility, and reader traffic
API	Stable client contracts, JWT validation, mobile OAuth, Google Play verification, push installations, analytics ingress	Provides a clear security and contract boundary for native and external clients
Worker	Source monitoring, transcript acquisition, AI workflows, research, scoring, scheduled tasks, push sends, distribution jobs	Isolates slow, failure-prone, and compute-heavy work from interactive requests

Why not put everything into Next.js?

For a small project, starting with one application is often the right choice. I did not separate services simply to follow a cloud architecture pattern.

The split became valuable because the workloads needed incompatible settings:

Web requests need low latency. AI tasks may run for minutes.
Web and API services benefit from warm instances. Background work should scale much more conservatively.
Worker pipelines frequently wait on external systems and need bounded retries.
Each warm service instance can open a PostgreSQL connection pool. Unbounded scaling can exhaust a small Cloud SQL instance long before CPU becomes the limiting resource.
A failed model call should not consume the same runtime capacity that serves public pages.

Putting all of this into one process would reduce the number of deployments, but it would combine unrelated failure domains and make performance settings a compromise everywhere.

Why not split every pipeline into its own service?

The opposite design would create separate YouTube, research, notification, social-distribution, and maintenance services. That would improve isolation, but it would also add deployments, IAM bindings, configuration, queue wiring, and operational surfaces.

At the current scale, the worker already provides the important boundary. Purpose-specific Cloud Tasks queues provide additional retry and concurrency isolation inside it. Separate services would mostly add ceremony.

This is an important distinction: 1 Minute Signal is a distributed application, but it is not a microservices program. It remains one product with one primary transactional database and a small number of runtimes that reflect genuinely different workloads.

The monorepo is the integration layer

All three services and the Android project live in an Nx monorepo with shared TypeScript packages for database access, authentication, API contracts, entitlements, feed rules, analytics, tags, AI calls, and research workflows.

The applications do not import and execute one another. They share stable domain packages.

That provides several benefits for a small team:

An entitlement rule can be used consistently by the web and API services.
Zod schemas and contract definitions keep client and server expectations aligned.
Feed-visibility predicates (ie, whether a piece of content meets the quality and relevance threshold to be visible and published) do not have to be reimplemented in multiple applications.
Model transport, retry, and usage behavior can be centralized without turning the worker into a remote internal platform.
A schema or package change can be tested across affected applications in the same repository.

The monorepo also introduces a deployment risk. Production images are pruned so they contain only the application and dependencies they need. NestJS builds can leave workspace packages as runtime imports. If a required compiled package is missing, the container can fail before it starts listening, and Cloud Run may report what looks like a generic port failure.

The deployment process now validates runtime imports inside the built image before it is pushed. That check came directly from a production failure mode and has more operational value than a more elaborate deployment diagram would.

The web application is more than a frontend

The Next.js service is the primary product surface and a backend-for-frontend.

It owns:

The public feed, signals, tags, research articles, and editorial pages
Authenticated account, history, feedback, and upgrade experiences
NextAuth web sessions
Server Components and route handlers that load finalized feed data
Staff tools and selected administrative proxies
Lemon Squeezy checkout, webhook verification, and customer-portal access

Not every request is routed through NestJS. That is intentional.

For web-only behavior, forcing an internal HTTP call from Next.js to NestJS would add latency and another failure point without creating a meaningful security boundary. Server-side web code can use shared database and domain packages directly.

The API is reserved for cases where the contract itself provides value: native mobile clients, bearer-token endpoints, mobile OAuth, Google Play billing, device registration, and analytics ingestion.

This is one example of choosing architectural consistency selectively. “All data must flow through the API” would produce a cleaner rule, but not a better product at this scale.

The same web deployable also supports adjacent properties through host-aware routing and internal namespaces. That kept me from creating a separate frontend deployment for every early product surface, but it required identity and authorization to be application-scoped rather than assuming that every user or token belongs to one global product. It is a practical example of accepting some routing complexity to avoid a larger deployment estate.

Android is a native shell around one product

The Android application is intentionally WebView-first. It reuses the web product for content, navigation, account UI, and entitlement-aware presentation while adding native capabilities where the browser is not sufficient.

The native layer owns:

Custom Tabs and PKCE authentication
Google Play Billing
Firebase Cloud Messaging registration and notification handling
A small JavaScript bridge for sign-in and push-permission interactions
Mobile product analytics

Custom Tabs and the embedded WebView do not automatically share cookies. The application therefore completes a mobile OAuth flow against the API and uses a controlled bootstrap process to establish the authenticated web session inside the WebView.

That creates some authentication complexity, but it avoids maintaining two separate feed products. Editorial layouts, Pro gating, and most user-interface changes ship once.

For an early product operated by one developer, that tradeoff is favorable. A fully native interface may become justified if offline behavior, platform-specific interaction, or mobile usage grows enough to outweigh the cost of maintaining another presentation layer.

PostgreSQL holds truth; BigQuery supports learning

Cloud SQL for PostgreSQL is the operational system of record. Prisma provides the main application data layer.

PostgreSQL holds data that must be correct for the product to behave correctly:

Users, sessions, OAuth state, device sessions, and roles
Subscription and entitlement state
Source channels, transcripts, signals, tags, scores, and authors
Research articles and their publication state
Read history, feedback, push installations, and delivery records
Billing-event and purchase records
Workflow state used for retries, deduplication, and recovery

Feed visibility is determined by stored fields and database predicates, not by whatever a model most recently returned. A model can propose content and scores. Application rules decide whether those outputs are complete enough to persist and which surfaces are allowed to display them.

BigQuery serves a different purpose. Product events are published through Pub/Sub into a raw analytics table for questions such as:

Which surfaces lead to account creation?
How frequently do people return?
Are mobile notifications opened?
Which content or sharing actions produce useful engagement?
Where does the upgrade funnel lose people?

The deliberate consistency rule is simple:

Operational updates are transactional. Analytics events are best-effort.

If a user action succeeds in PostgreSQL and the associated analytics publish fails, the user action remains successful. The application should not reject a signup, feedback submission, or account operation because a warehouse event could not be delivered.

That is appropriate because BigQuery is used to learn about the product, not to decide access or reconstruct current state. If an event ever becomes important enough to require guaranteed delivery, it should move to a transactional audit table or an outbox pattern rather than relying on hope and retries in the request path.

Other storage services play narrower roles. Google Cloud Storage holds selected private artifacts and media. Secret Manager supplies runtime secrets. Langfuse stores optional AI traces but is not a source of product truth.

Scheduled work becomes durable work

Most recurring and long-running jobs follow one production pattern:

Cloud Scheduler sends an authenticated HTTP request to the worker's enqueue endpoint.
The enqueue handler creates one or more Cloud Tasks on a purpose-specific queue.
Cloud Tasks invokes an authenticated worker execution endpoint.
The worker runs the job, waits for its required steps, records the result, and returns an HTTP status that determines whether the task should be retried.

Queues are separated by purpose, including source polling, YouTube processing, research, distribution, push notifications, and account deletion. That provides targeted concurrency, timeouts, retry behavior, and operational visibility without requiring another service for every category.

Earlier versions used Pub/Sub more broadly for worker triggers. Cloud Scheduler plus Cloud Tasks became the better fit because the jobs map naturally to authenticated Cloud Run requests with explicit execution deadlines and retry semantics.

Pub/Sub remains where its fan-out and integration model fit well: analytics delivery and Google Play real-time developer notifications.

How one video becomes a published signal

The core content workflow is a useful example of how the layers work together.

1. Discover

The worker monitors an approved set of source channels and discovers recent uploads through the YouTube Data API. Database state prevents the same video from being treated as new every time a channel is checked.

2. Acquire the transcript

The system attempts to retrieve a transcript through a provider chain, currently centered on Supadata with additional fallback behavior where appropriate. Outcomes are not reduced to success or failure. A missing transcript, provider quota condition, retryable error, and permanently failed item require different next steps.

That state matters because blindly retrying every miss wastes money and can create a queue that never drains.

3. Compress the source material

Long transcripts first become a dense internal knowledge representation. This removes repetition and organizes the useful substance while preserving enough detail for later stages.

Separating compression from the public summary reduces the amount of irrelevant text passed through subsequent prompts and gives other stages a cleaner source from which to work.

4. Produce structured content

The system generates structured metadata and the reader-facing signal. Important outputs use strict JSON schemas and domain validation. Transport success is not enough. If a model returns valid JSON that is missing required substance, the pipeline treats that as a failed attempt and applies bounded retries.

This distinction is essential in production AI systems. “The API returned 200” does not mean the product received something usable.

5. Enrich

The model proposes tags, which are resolved against the site's controlled tag catalog. An optional timestamp breakdown can also be generated.

Not every enrichment has equal importance. A missing timestamp breakdown is allowed to fail softly. Structurally incomplete core content is not. The pipeline's failure policy reflects product consequences rather than treating every field identically.

6. Score and gate

Quality and relevance are scored separately. Database rules then determine where an item is eligible to appear.

Current thresholds are intentionally progressive: the public corpus has a lower bar, the main curated feed requires stronger quality and relevance, and push notifications require the highest confidence. As one simplified example, the system has used thresholds around 5/5 for public eligibility, 7/7 for the main feed, and 9 quality with at least 7 relevance for push consideration.

The exact numbers can change as the scoring system improves. The architectural principle is more important: a generated item is not automatically a published item, and publication to one surface does not imply promotion to every surface.

7. Persist first, serve later

The completed signal, analysis, tags, scores, and eligibility state are stored in PostgreSQL. The web and Android experiences read those finished rows.

No OpenRouter call builds the home feed. No model starts writing an analysis when a Pro user opens the page. Paid analysis is stored content revealed through entitlement checks.

This keeps reader-facing performance predictable and makes the published result inspectable, correctable, and cacheable.

The dedicated signal-pipeline Build Note goes deeper into monitoring, provider fallback, structured outputs, scoring, and failure recovery.

AI providers are adapters, not the architecture

Production model calls flow through a shared AI package and OpenRouter. Individual workflow stages can use different model configuration without changing the orchestration code.

That separation provides:

Central transport behavior and usage capture
Layered retries for network, parsing, schema, and domain failures
Per-stage model configuration
A consistent place to add tracing and cost metadata
Less dependence on one model vendor's client library

Langfuse receives sampled traces for supported production workflows and complete traces in selected administrative testing contexts. Tracing is fail-open. If Langfuse is unavailable, the content workflow continues and Google Cloud structured logs remain the operational fallback.

The architecture avoids a single open-ended agent responsible for discovering, researching, judging, writing, and publishing. Each stage has a bounded responsibility, explicit inputs and outputs, and known failure behavior. Models exercise judgment inside the workflow, but deterministic code controls the workflow itself.

The research-article pipeline uses the same broad infrastructure pattern but remains a distinct product workflow. It assembles a much larger source set, develops research artifacts, identifies claims and contradictions, supports drafting and revision, and publishes only after its own quality controls. Treating it as “the longer summarizer” would hide the decisions that make it useful.

Authentication and commerce follow the client boundary

Web and Android users ultimately receive the same product access, but they reach it through different platform mechanisms.

Web authentication uses NextAuth sessions. Android uses a Custom Tabs and PKCE flow against the API, followed by the controlled session bootstrap needed by the embedded web experience.

Commerce is also split by platform:

Lemon Squeezy handles hosted checkout and subscription management for the web.
Google Play Billing handles Android purchases.

Both paths converge on a single server-managed entitlement ledger in PostgreSQL. Clients cannot directly set their plan. Webhooks, purchase tokens, real-time notifications, and reconciliation jobs are triggers for server-side verification, not proof by themselves.

Shared entitlement code controls whether Pro analysis is returned or redacted. That prevents the web and API layers from gradually developing different definitions of access.

This is an area where production rigor is worth more than implementation speed. A broken analytics event is inconvenient. A client-controlled entitlement or an unverified billing notification is a security and revenue problem. The architecture treats them accordingly.

Infrastructure is code, but deployment remains deliberately understandable

Pulumi defines the active Google Cloud infrastructure, including Cloud Run services, Cloud Tasks queues, Scheduler jobs, Pub/Sub resources, IAM, and supporting configuration. Cloudflare provides DNS and selected redirects. Google-managed domain mappings terminate origin TLS.

Source control and narrow automated checks live in GitHub. Deployment is still operator-driven through a PowerShell script rather than a fully automated continuous-deployment pipeline.

The deployment sequence performs the important steps explicitly:

Build the service image.
Validate required runtime dependencies inside the image.
Push the image to Artifact Registry.
Apply database migrations when required.
Synchronize infrastructure configuration.
Run the Pulumi update.

A fully automated pipeline would be reasonable later. At the current change volume, an observable operator-driven release is easier to reason about and recover than automation that adds complexity without removing a real bottleneck.

Scaling is constrained by the database, not by marketing claims

The web and API services maintain warm instances to reduce cold starts. They also have explicit maximum instance counts.

Cloud Run can scale faster than a small Cloud SQL tier can accept new connection pools. The relevant capacity calculation is not simply request volume. It is closer to:

maximum service instances × database pool size < safe PostgreSQL connection budget

The actual budget must also leave room for migrations, administrative access, the worker, and operational headroom.

Explicit caps are less exciting than “automatically scales to zero or infinity,” but they prevent a traffic increase from turning into a connection storm. If the product outgrows the current design, database pooling, larger instances, read patterns, and service limits can evolve from measured demand.

The worker uses low-cost compute and conservative concurrency for expensive jobs. Many AI pipelines run at concurrency one per task executor because parallelizing external calls and database work without a budget can increase cost and failure rate faster than throughput.

Production-grade does not mean maximally elaborate

Some parts of the platform are mature because mistakes there affect readers, money, privacy, or recoverability:

Server-verified web and mobile entitlements
App-scoped authentication and mobile PKCE
Durable background tasks with authenticated execution
Stored, score-gated content rather than request-time generation
Explicit database connection budgets
Runtime dependency validation before deployment
Structured workflow state and bounded retries
Shared access and feed rules

Other parts remain intentionally simple or transitional:

Product analytics are best-effort rather than backed by a transactional outbox.
Deployment is operator-driven rather than full CI/CD.
Android uses the web product instead of duplicating the interface natively.
Langfuse coverage and evaluation workflows are still expanding.
Some legacy content fields remain dual-written during format migration so rollback stays possible.
Edge protection, warehouse erasure automation, and database pooling can become more sophisticated if actual usage justifies them.

Holding both lists at once is the point. Production-grade engineering is not the number of technologies in the diagram. It is knowing which failures the product must prevent now, which it must recover from, and which complexity can wait.

What would change at larger scale

The current architecture has clear evolution paths without requiring them prematurely.

If reader traffic increased substantially, I would revisit caching, database read patterns, connection pooling, and independent scaling limits before dividing the application into more domain services.

If worker volume became the constraint, the first likely move would be separating the heaviest workflow families into independently sized worker services while preserving the same task and shared-package model.

If analytics events became operationally important, I would add a transactional outbox and explicit delivery state.

If the Android experience required substantial offline or platform-specific behavior, more of the product could move native while keeping the API and entitlement boundaries already in place.

If release frequency or team size increased, automated deployments, preview environments, stronger policy checks, and progressive rollout controls would provide more value.

The goal is not to avoid those systems forever. It is to add them when the problem exists and when their operational cost is justified.

The architecture in one content lifecycle

A single source item ties the whole system together:

Cloud Scheduler wakes the worker's enqueue endpoint.
The worker creates a purpose-specific Cloud Task.
The task invokes the worker with authenticated execution.
The worker discovers a new video and records its state in PostgreSQL.
Transcript providers and staged model calls produce validated internal and reader-facing output.
The worker resolves tags, assigns quality and relevance scores, and persists publication eligibility.
A separate task may send a push notification if the item clears the higher threshold.
A browser or Android WebView requests the feed from the web service.
Stored predicates determine whether the signal appears, and shared entitlement logic determines whether Pro fields are revealed.
Product events may flow through Pub/Sub into BigQuery without affecting whether the content was served.

The system is asynchronous where work is slow, transactional where correctness matters, and best-effort where losing an event is preferable to breaking the product.

That is the central architecture of 1 Minute Signal.

It is sophisticated where the product has earned sophistication: long-running AI work, content quality, authentication, billing, recoverability, and production operations. It stays intentionally plain where managed services and a simpler implementation are enough.

The models work in the factory. Readers visit the storefront and find finished goods.

This article is part of Build Notes, a firsthand series about designing, building, and operating 1 Minute Signal. Start with Why I Built 1 Minute Signal, or continue with How 1 Minute Signal Turns YouTube Channels Into a High-Signal Intelligence Feed.