Overview
Ceres API is the core backend platform of the Government of the City of Ceres. It started as an Express backend to support Ceresito and internal panels, but with system growth it became monolithic, difficult to scale, coupled, and with no security or observability guarantees. I currently lead an incremental migration to NestJS aimed at turning this backend into a modular, scalable, secure and maintainable platform, without disrupting critical services in production.
Problem
The legacy backend had multiple limitations: monolithic and highly coupled architecture; no API versioning; no formal authentication or authorization; no tests or clear contracts; difficult to scale and maintain; no real observability. Additionally, a full rewrite was not viable due to critical systems in production, dependencies with bots, dashboards and public services, and unacceptable operational risk.
Solution
I designed an incremental migration strategy by domain, maintaining compatibility with existing endpoints while modernizing the architecture: backend rewritten in NestJS 11; modularization by business domains; typed contracts with DTOs and validation; base infrastructure with healthchecks, optional Redis and centralized configuration; observability with Prometheus + Grafana; functional parity strategy between legacy and new backend; module-by-module migration without downtime. The legacy system continues to operate while modules are progressively routed to the new backend through a controlled transition pattern.
My Role
I am responsible for: backend architecture design; zero-downtime migration strategy definition; data modeling and API contracts; base infrastructure implementation; observability and monitoring; repository organization, branching strategy and DX; technical documentation for each phase.
Technical Architecture
Framework: NestJS 11 + TypeScript ORM: TypeORM (synchronize false) Database: PostgreSQL Cache / Infra: Redis (optional) Observability: Prometheus + Grafana Security (in progress): JWT + roles + API keys Infrastructure: Docker Documentation: OpenAPI + phased migration documentation The architecture is designed to evolve towards microservices if needed, initially maintaining a modular and versioned monorepo.
Migration Strategy
- 1Base infrastructure first (config, DB, Redis, health)
- 21:1 entity migration with legacy tables
- 3Definition of compatible DTOs and contracts
- 4Migration by modules: Analytics / Contacts → Complaints → Surveys + Redis → Notifications → Taxes → BotConfig / Feedback / Voters → Pharmacies / Duty
- 5Functional parity validation with legacy backend before moving traffic
Impact
Backend prepared to scale by domains Drastic reduction in coupling Solid base for authentication, versioning and testing Real observability in production Reduction of future operational risk
Key Learnings
- Incremental migration of legacy systems without downtime
- Design of scalable backend platforms
- Domain-oriented modular architecture
- Observability and reliability in production
- Evolution of monoliths towards modern systems without total rewrite