They become difficult to operate because everything around the page starts multiplying.

One application needs a content system. Another needs analytics. Another needs transactional email. Another needs payment integrations. Then come background jobs, webhooks, domain management, authentication, file storage, notifications, AI services, observability, and internal tooling.

At first, each integration looks harmless.

Then the architecture starts looking like this:

                    ┌──────────────┐
                    │   Frontend   │
                    └──────┬───────┘
                           │
          ┌────────────────┼────────────────┐
          │                │                │
       CMS API         Analytics API    Email API
          │                │                │
       Payment         Automation       AI API
          │                │                │
       Storage           Queue          Search
          │                │                │
       Webhooks        Monitoring       Domains
          │                │                │
          └────────────────┴────────────────┘

Every service introduces another API, another set of credentials, another failure mode, and another operational surface.

We started GN-Apex around a different architectural question:

What would it look like to build a unified infrastructure control plane without turning everything into one giant application?

That question shaped almost every major engineering decision we made.

Problem Is Not Microservices vs Monoliths

A common architectural debate asks:

“Should we build a monolith or microservices?”

That was not the problem we were trying to solve.

The real problem was coupling.

A system can be distributed across ten services and still behave like a monolith if every request synchronously depends on everything else.

For example:

Request
  │
  ├── CMS
  │    └── Database
  │
  ├── Analytics
  │    └── Redis
  │
  ├── Notifications
  │    └── Email provider
  │
  ├── Payments
  │    └── Provider
  │
  └── AI
       └── Model service

If five of those dependencies must respond before the request can complete, you have created a distributed monolith.

Our goal was therefore not:

“Put every feature in a separate service.”

It was:

Give each subsystem a clear responsibility and make communication between subsystems explicit.

That distinction matters.

The Control Plane Model

We eventually approached GN-Apex as a digital infrastructure control plane.

The control plane is responsible for coordinating things such as:

• tenants

• workspaces

• projects

• configuration

• authentication

• service orchestration

• jobs

• integrations

• application state

Specialized services handle workloads that have very different performance or operational characteristics.

A simplified architecture looks like this:

                           GN-Apex
                              │
                  ┌───────────┴───────────┐
                  │                       │
           Control Plane             Data Plane
                  │                       │
          ┌───────┼────────┐      ┌───────┼──────────┐
          │       │        │      │       │          │
       API      Auth    Config   Events  Analytics  Workers
          │       │        │      │       │          │
          └───────┴────────┘      └───────┴──────────┘
                  │                       │
                  └───────────┬───────────┘
                              │
                       Infrastructure

This gives us an important property:

The orchestration layer does not need to implement every workload itself.

Why We Chose Explicit Service Boundaries

Consider analytics.

Analytics traffic behaves very differently from configuration traffic.

A configuration request might look like:

POST /workspaces/:id/settings

A telemetry collector may receive thousands of independent events:

{
  "event": "page_view",
  "session_id": "sess_123",
  "path": "/pricing"
}

Trying to make both workloads behave identically creates unnecessary pressure on the system.

The same applies to:

• email delivery

• background jobs

• AI inference

• payment webhooks

• content publishing

• scheduled automation

We therefore separate responsibilities according to workload characteristics, not simply according to feature names.

The Orchestrator

The central API layer is responsible for coordinating platform state and exposing a consistent API.

A TypeScript/NestJS service works well for this role because much of the work is orchestration:

Client
   │
   ▼
API Gateway / Orchestrator
   │
   ├── Authentication
   ├── Tenant resolution
   ├── Authorization
   ├── Configuration
   ├── Project state
   ├── Job dispatch
   ├── Webhooks
   └── Service coordination

The important design principle is:

The orchestrator should coordinate work, not become the place where every workload executes.

That keeps the control plane understandable.

Database Boundaries

One of the easiest ways to accidentally create coupling is to let every service directly manipulate the same database tables.

We avoid treating the database as a shared API.

Instead, services own particular data responsibilities.

Conceptually:

                Control Plane
                     │
                  PostgreSQL
                     │
       ┌─────────────┼─────────────┐
       │             │             │
    Tenants       Projects      Config

Meanwhile, workloads with different storage characteristics can use specialized systems.

For example:

Transactional state  → PostgreSQL
Document-oriented     → MongoDB
Object storage        → MinIO
Fast coordination     → Redis
Event streams         → Redis Streams

The exact technology is less important than the principle:

Choose storage based on workload semantics rather than forcing every problem into one database.

Why Events Matter

One of the biggest improvements to a platform like this comes from treating many operations as events.

Suppose a user submits a form.

A naive implementation could do this:

HTTP Request
   │
   ├── Validate form
   ├── Save database record
   ├── Send email
   ├── Send notification
   ├── Update analytics
   └── Trigger automation

The request now depends on every downstream operation.

Instead:

HTTP Request
   │
   ▼
Validate
   │
   ▼
Persist
   │
   ▼
Publish Event
   │
   └── form.submitted
          │
          ├── Analytics
          ├── Email
          ├── Notifications
          └── Automation

The initial request becomes much simpler.

The system can also retry individual consumers without repeating the original request.

Redis Streams and Background Processing

For event-oriented workloads, streams and queues become extremely useful.

A simplified event flow looks like:

Producer
   │
   ▼
Redis Stream
   │
   ├─────────────┐
   ▼             ▼
Consumer A    Consumer B
   │             │
Analytics      Notifications

This provides several useful properties:

• asynchronous processing

• independent consumers

• retryable workloads

• reduced request latency

• workload isolation

• easier horizontal scaling

For task-oriented work, a queue such as BullMQ can provide a different abstraction:

Application
    │
    ▼
Queue
    │
    ├── Worker 1
    ├── Worker 2
    └── Worker 3

The distinction matters.

Streams are useful when the event itself is valuable to multiple consumers.

Queues are useful when a task should be processed by workers.

They solve related but different problems.

Why Rust for Analytics?

Analytics collection is another interesting architectural boundary.

Telemetry workloads are:

• high frequency

• latency sensitive

• largely stateless at ingestion time

• suitable for batching

• naturally asynchronous downstream

That is a different workload from administrative API operations.

For the analytics ingestion layer, we use Rust with Actix Web.

A simplified ingestion pipeline is:

Browser / SDK
      │
      ▼
Analytics Collector
      │
      ├── Validate
      ├── Normalize
      ├── Enrich
      └── Buffer
             │
             ▼
        Event Stream
             │
       ┌─────┴─────┐
       ▼           ▼
   Processing    Storage

The collector should do as little expensive work as possible.

Its job is primarily:

accept → validate → normalize → enqueue

Expensive analytics computation belongs downstream.

Designing the Analytics Event

An event schema should be boring.

That is a compliment.

A predictable envelope is easier to validate, version, and process:

interface AnalyticsEvent {
  event: string;
  timestamp: number;
  sessionId?: string;
  path?: string;
  properties?: Record<string, unknown>;
}

In production systems, the schema can be extended with:

event_id
tenant_id
project_id
timestamp
session_id
request_id
source
properties
schema_version

The important part is that event consumers should not have to guess what an event means.

Schema Versioning

Distributed systems eventually encounter this problem:

Producer: schema v3
Consumer: schema v2

If the producer simply changes the structure, an old consumer may break.

Versioning the event contract allows both versions to coexist while consumers migrate independently.

For example:

{
  "schema_version": 2,
  "event": "page_view",
  "timestamp": 1760000000,
  "properties": {
    "path": "/docs"
  }
}

This tiny field can save a surprising amount of operational pain later.

Multi-Tenancy Is More Than Adding tenant_id

When building infrastructure for multiple organizations, simply adding:

tenant_id

to every table is not enough.

Multi-tenancy affects almost every layer:

Authentication
      │
      ▼
Tenant resolution
      │
      ▼
Authorization
      │
      ▼
Data access
      │
      ▼
Jobs
      │
      ▼
Events
      │
      ▼
Analytics

A background worker must know which tenant owns a job.

An event must know which tenant produced it.

An analytics event must not accidentally become visible to another workspace.

A cached object must have an appropriate tenant boundary.

Even logs need tenant context.

Tenant Context Propagation

We therefore treat tenant context as part of the request and event lifecycle.

Conceptually:

type RequestContext = {
  tenantId: string;
  workspaceId?: string;
  requestId: string;
};

That context then follows the work:

HTTP Request
     │
     ▼
Request Context
     │
     ├── Database operation
     ├── Queue job
     ├── Event
     ├── Log
     └── Trace

This is one of those architectural decisions that looks small early on and becomes enormous later.

Idempotency

Distributed systems retry.

Networks fail.

Workers restart.

Providers timeout.

A webhook may arrive twice.

Therefore, important operations should be designed around idempotency.

Suppose a payment provider sends:

payment.completed

and the same webhook arrives twice.

Without idempotency:

Webhook
   │
   ├── update payment
   ├── create record
   └── send notification

Webhook again
   │
   ├── update payment
   ├── create duplicate record
   └── send duplicate notification

Instead:

Webhook
   │
   ▼
Event ID
   │
   ▼
Already processed?
   │
 ┌─┴───────────┐
 │             │
Yes            No
 │             │
Ignore       Process

The exact mechanism can vary, but the invariant should remain:

Retrying the same operation should not unexpectedly duplicate its side effects.

Webhooks Are Distributed Systems Problems

Webhooks look simple:

POST /webhooks/provider

In reality, they're one of the most failure-prone integration boundaries.

A robust webhook handler should consider:

Signature verification
        │
        ▼
Payload validation
        │
        ▼
Idempotency
        │
        ▼
Persistence
        │
        ▼
Async processing

The HTTP handler itself should avoid long-running work whenever possible.

Instead:

Provider
   │
   ▼
Webhook endpoint
   │
   ├── verify
   ├── validate
   └── persist
          │
          ▼
        Queue
          │
          └── Worker

This protects the integration from temporary downstream failures.

Security at the Boundaries

A control plane has many trust boundaries.

For example:

Browser
   │
Internet
   │
API
   │
Internal services
   │
Databases

Every boundary needs explicit assumptions.

For external requests, this can include:

• authentication

• authorization

• schema validation

• rate limiting

• request size limits

• signature verification

• replay protection

• safe error handling

• audit logging

For internal communication:

Service A
   │
   ├── authenticated request
   ├── validated payload
   └── explicit contract
        │
        ▼
Service B

Internal does not automatically mean trusted.

Failure Isolation

One of the biggest advantages of this architecture appears when something breaks.

Suppose the AI service is unavailable.

A bad architecture might produce:

AI unavailable
     │
     ▼
API blocked
     │
     ▼
Dashboard unavailable
     │
     ▼
Entire platform degraded

A better architecture allows:

AI unavailable ────────┐
                       │
                       ▼
                 AI-dependent jobs
                       │
                  Retry / Defer

Core API ──────────────► Still operating
Analytics ─────────────► Still operating
CMS ───────────────────► Still operating

This is the real reason for service boundaries.

Not organizational fashion.

Failure containment.

Graceful Degradation

Not every dependency should have the same availability requirements.

For example:

Critical
├── Authentication
├── Core API
└── Database

Important
├── Analytics
├── Notifications
└── Background jobs

Optional
├── AI enrichment
├── Recommendations
└── Secondary integrations

If an optional subsystem is unavailable, the user should ideally still be able to perform the core action.

This leads to a useful engineering question:

What is the minimum functionality required for this request to succeed?

Everything else can often happen asynchronously.

Building the Developer Layer

Infrastructure is not complete when the servers work.

Developers need an interface.

That is why the developer layer matters as much as the backend.

GN-Apex uses a TypeScript-oriented developer experience around its APIs and SDK.

The objective is to move integration from:

Raw HTTP
   │
   ▼
Manual authentication
   │
   ▼
Manual payload construction
   │
   ▼
Manual error handling

toward:

const client = createGNAPEXClient({
  apiKey: process.env.GNAPEX_API_KEY,
});

const content = await client.content.get("homepage");

The SDK becomes the boundary between application code and infrastructure.

The CLI Is Part of the Architecture

Command-line tooling may appear unrelated to distributed systems.

It isn't.

A CLI defines how developers interact with the platform.

For example:

npx apex init
npx apex pull
npx apex push
npx apex studio

Those commands can become the interface for:

Project initialization
Configuration
Content synchronization
Local development
Deployment workflows

A good developer experience is effectively an operational API for humans.

Keeping the Frontend Separate

GN-Apex uses Next.js for application and product experiences.

This is intentionally separate from the specialized backend workloads.

                    Browser
                       │
                       ▼
                   Next.js
                       │
                ┌──────┴──────┐
                ▼             ▼
          Control API      Content API
                │
          ┌─────┴─────────┐
          ▼               ▼
      Platform         Services

This separation lets frontend experiences evolve without forcing backend services to share frontend concerns.

It also enables specialized experiences such as education, NGO, agency, commerce, and other workspace-oriented products while preserving a common infrastructure layer underneath.

Observability Has to Be Designed In

Distributed architecture creates another problem:

How do you know where something failed?

A request can travel through:

Browser
  ↓
Next.js
  ↓
API
  ↓
Queue
  ↓
Worker
  ↓
Database
  ↓
External provider

A single error message isn't enough.

We want contextual observability:

request_id
tenant_id
workspace_id
service
operation
timestamp
status
latency

This gives us a chain of evidence rather than isolated logs.

A useful mental model is:

Logs      → What happened?
Metrics   → How often?
Traces    → Where?
Events    → What changed?

These systems complement one another.

The Most Important Architectural Rule

After working on the platform, one rule became increasingly important:

Do not distribute a system merely to make it distributed.

A separate service has a cost.

It introduces:

• deployment complexity

• network boundaries

• observability requirements

• versioning

• contracts

• failure modes

• operational overhead

A service should exist because its boundaries provide a meaningful benefit.

Usually one of these:

Different workload
Different scaling characteristics
Different failure domain
Different runtime requirements
Different security boundary
Different ownership
Different data lifecycle

Rust analytics is a good example.

A telemetry ingestion service has fundamentally different characteristics from a control-plane API.

That is a meaningful boundary.

Creating twelve services because "microservices are scalable" is not.

What We Learned

Building a platform like this changed the way we think about architecture.

1. Simplicity matters more than fashionable architecture

Microservices are tools, not goals.

2. Asynchronous work should become the default for non-critical side effects

Email, notifications, analytics, and automation rarely need to block the original request.

3. Tenant isolation must exist everywhere

Not only in database queries.

4. Every distributed operation should consider retries

Assume networks fail and workers restart.

5. APIs need contracts

Loose JSON everywhere eventually becomes technical debt.

6. Specialized runtimes can be valuable

Use the runtime that fits the workload.

7. Observability is part of architecture

It shouldn't be added after the distributed system already exists.

Where This Architecture Leads

The interesting part of a control-plane architecture is that it creates a foundation for many different applications.

The same underlying infrastructure can support different products:

                         GN-Apex
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
        EduOS            Analytics         Payments
          │                 │                 │
       Schools         Developers         Businesses
          │                 │                 │
          ├───────────────┬─┴───────────────┤
                          │
                    Shared Platform
                          │
          ┌───────────────┼───────────────┐
          │               │               │
         CMS           Identity        Automation
          │               │               │
          └───────────────┼───────────────┘
                          │
                     Developer SDK

The products can have different user experiences without requiring completely separate infrastructure stacks.

That is one of the reasons we think of GN-Apex as a control plane rather than simply another SaaS application.

Final Thought

The hardest part of building infrastructure is not choosing technologies.

It is choosing boundaries.

Where should state live?

Which service should own it?

Which operations must be synchronous?

Which operations can become events?

What happens when a dependency disappears?

What happens when a request is duplicated?

What happens when two tenants use the same capability simultaneously?

What should remain available when a subsystem fails?

Those questions are more important than whether a particular service is written in TypeScript, Rust, Python, or something else.

At GN-Apex, our architecture continues to evolve around those questions.

The goal is not to build the most complicated infrastructure.

It is to build infrastructure where complexity is contained, observable, and useful.

That is the engineering challenge behind a digital infrastructure control plane.

About GN-Apex

GN-Apex is a digital infrastructure platform focused on providing a unified foundation for modern applications and organizations.

Its ecosystem includes infrastructure for content, analytics and telemetry, communications, payments, automation, AI capabilities, and developer tooling.

The platform started in Tanzania and is being designed for applications and organizations operating beyond a single market.

Build. Host. Sell. Automate. Connect. Grow. Scale.