Building StudEd: A Cloud-Native Microservices Platform for Learning

Building StudEd started as an educational platform project, but it quickly became much more than just building a web application.

As the system grew, I found myself working with Go microservices, GraphQL, gRPC, Kubernetes, OpenTofu, GitOps, observability, cloud security, and local cloud emulation.

This article is a look at how those technologies come together to power StudEd and, more importantly, what I learned while building it.

---

What is StudEd?

StudEd is a cloud-native educational platform designed to provide a modern learning experience while keeping the underlying system scalable and maintainable.

Instead of building everything inside one large backend, StudEd is divided into independent services, each responsible for a specific part of the platform.

The architecture was designed around an important idea:

The application should be easy to develop, easy to deploy, and easy to observe as it grows.

That naturally led me toward a microservices architecture.

---

The Architecture

At a high level, the system looks like this:

Clients → Edge Layer → API Gateway → Microservices → Data Layer

Around that core flow sits the platform infrastructure responsible for deployment, security, secrets, infrastructure provisioning, and observability.

The diagram above shows how the different layers connect and how requests move through the platform.

---

Go Microservices at the Core

The backend is built with Go (Golang) and divided into domain-focused microservices.

Some of the main services include:

• API Gateway — provides the main GraphQL interface for clients.
• Auth Service — handles authentication, tokens, and permissions.
• Course Service — manages courses, curriculum, and learning content.
• Progress Service — tracks student progress and completion.
• Gamification Service — handles XP, achievements, and leaderboards.
• AI Service — provides intelligent learning and content-related features.
• Payment Service — manages payment workflows.
• Notification Service — handles application notifications.
• Upload Service — manages media and document uploads.

Each service has its own responsibility rather than everything being handled by one large codebase.

This makes the platform easier to evolve because individual services can be developed and deployed independently.

---

GraphQL for the Client, gRPC Between Services

One of the architectural decisions I found particularly interesting was using two different communication patterns.

For the frontend, StudEd exposes a unified GraphQL API.

For communication between backend services, it uses gRPC with Protocol Buffers.

So the flow is essentially:

Frontend → GraphQL → API Gateway → gRPC → Microservices

GraphQL gives the client a flexible API, while gRPC provides strongly typed and efficient communication between internal services.

Using Protocol Buffers also gives the services explicit contracts, making the boundaries between them much clearer.

---

Choosing the Right Data Store

Not everything belongs in the same database.

StudEd uses different technologies for different workloads.

PostgreSQL

Neon Serverless PostgreSQL is used for relational application data that needs strong transactional consistency.

Redis

Redis handles fast-changing state such as caching, token-related operations, sessions, and rate limiting.

Elasticsearch

Elasticsearch powers advanced search across courses, instructors, lessons, and other content, including support for fuzzy and internationalized text search.

This approach lets each component use a storage system that fits its job instead of forcing the entire platform into one database.

---

Kubernetes and Platform Engineering

Once you have multiple services, deployment becomes a problem of its own.

StudEd runs on Kubernetes, with the production architecture built around Google Kubernetes Engine (GKE).

The platform also uses several tools around Kubernetes:

ArgoCD

ArgoCD provides the GitOps workflow.

Instead of manually changing cluster resources, the desired state lives in Git and ArgoCD continuously reconciles the cluster with that state.

Kyverno

Kyverno is used to enforce Kubernetes policies such as secure container configurations, immutable image references, and resource limits.

External Secrets Operator

Secrets are kept outside application manifests and synchronized into Kubernetes through External Secrets Operator and Google Secret Manager.

Network Policies

The cluster follows a default-deny, zero-trust approach, controlling which services are allowed to communicate with each other and where workloads can send traffic.

This is where StudEd moved from simply being a backend project into something much closer to a real platform engineering environment.

---

OpenTofu: Infrastructure as Code

I didn't want the infrastructure to depend on manual setup.

That is where OpenTofu comes in.

The infrastructure is defined declaratively so networking, compute, security, storage, and other cloud resources can be reproduced consistently.

The same infrastructure approach can also target local cloud emulation environments during development.

That makes the infrastructure part of the project itself rather than something that exists separately from the code.

---

Floci: Building the Cloud Locally

One of the tools I particularly wanted to experiment with was Floci.

Cloud development can get expensive and slow when every small test requires real cloud resources.

Floci gives the project local emulation for cloud services such as:

• Cloud Storage
• Secret Manager
• Pub/Sub

This means I can test cloud-dependent functionality locally without constantly deploying to a real environment.

For me, this became especially useful for the developer inner loop: build locally, test locally, then move toward the actual cloud environment.

---

Containers Everywhere

StudEd is containerized using Docker and Podman.

The services use multi-stage builds so development dependencies and compiler tooling don't have to end up inside the final runtime image.

This keeps the containers smaller and reduces unnecessary components in production images.

---

Observability Is Not an Afterthought

When you have a single application, finding a problem can be relatively straightforward.

With multiple microservices, it gets much harder.

A request can travel through the API Gateway, several services, a database, Redis, and external systems before the user sees a response.

That is why StudEd includes a dedicated observability stack built around:

OpenTelemetry + Prometheus + Grafana + Tempo

OpenTelemetry provides distributed tracing across services.

Prometheus collects application and infrastructure metrics.

Grafana turns those metrics into operational dashboards.

Tempo stores and visualizes distributed traces.

Together, they make it possible to move from:

"Something is slow."

to:

"This specific service or database operation caused the slowdown."

---

The Frontend and Delivery Pipeline

On the client side, StudEd uses TypeScript, Vite, and Bun, with the frontend deployed through Cloudflare Pages.

The delivery pipeline is built around GitHub Actions, container registries, automated validation, and GitOps deployment.

This means the development workflow is not simply:

write code → manually deploy

Instead, code moves through a controlled pipeline before reaching the running environment.

---

The Technology Stack

The important part isn't simply the number of technologies.

It's how they work together to solve different problems across the platform.

---

What I Learned Building StudEd

StudEd taught me that building a distributed system is very different from simply building an application.

Writing a microservice is one thing.

Deciding where that service belongs, how it communicates, how it is deployed, how its secrets are managed, how it is observed, and how developers can reproduce its environment locally is a completely different challenge.

The biggest lesson for me was that technologies such as Kubernetes, OpenTofu, ArgoCD, OpenTelemetry, and Floci aren't isolated tools.

They become useful when they work together as part of a platform.

And that is the part of StudEd I enjoyed the most: taking an educational product idea and using it as a practical playground for learning cloud-native engineering and platform engineering.

---

Final Thoughts

StudEd is still evolving, but the architecture has already given me hands-on experience with many of the ideas behind modern cloud-native systems.

From Go microservices and gRPC to Kubernetes, GitOps, Infrastructure as Code, local cloud emulation, and distributed observability, the project has become much more than an educational application.

It has become a way for me to understand what happens behind the application.

And honestly, that's where things get interesting.