Language Learning App
Decks and minigames on a microservices backend speaking gRPC across three data stores.
Role
Backend developer — team of 3
Stack
Go, gRPC, Protobuf, PostgreSQL
Language
Go
Repository
Link pending
Problem
Decks, user progress, and minigame state have different shapes and access patterns — one storage engine would force awkward compromises for at least one of them.
Solution
The full backend of a language-learning app (decks & minigames) designed as a microservices architecture with gRPC/Protobuf for inter-service communication.
My contribution
Designed and implemented the full backend as microservices in Go; chose the storage per service: PostgreSQL, MongoDB, and SQLite, depending on data shape and access pattern (Jul 2023 – Jan 2024).
Architecture
Services communicate over gRPC with Protobuf contracts. Deck content lives in PostgreSQL (relational integrity), user progress in MongoDB (document-shaped, write-heavy), and lightweight per-device state in SQLite.
Overview
The app's backend serves deck management, learning progress, and minigames as separate services. Each service owns the storage engine that fits its data shape and access pattern.
Technical Decisions
Three data stores across services: PostgreSQL for relational deck content, MongoDB for document-shaped progress data, SQLite for lightweight local state. gRPC/Protobuf contracts keep the boundaries explicit.
Results
A microservices backend demonstrating that storage choice is a design decision per service — not a global one.
The hard part
Keeping inter-service contracts stable while services own different storage engines — a schema change in one store must not silently break another service.
A decision worth noting
Made Protobuf the single source of truth for service contracts. Polyglot persistence per data shape instead of one-engine-everywhere.
Outcome
A working microservices backend demonstrating contract-first design and polyglot persistence trade-offs.
Next project
Terminal Chess