[AVAILABLE · REMOTE]
Carlos Morales

Carlos Morales

Backend Developer · Recent Graduate

The invisible
engine.

Recently graduated Backend Developer. I build systems with real architectures, microservices, AI pipelines, algorithmic trading, and data analysis. Looking for my first remote opportunity.

# Projects

What I've built

Five systems with real architectures. Microservices, AI, financial data, and algorithmic trading.

[ BACKEND / SYSTEMS ]Working

Ticketing System

High-concurrency ticket sales with zero double-booking, guaranteed under real load

0%

Double-booking under concurrency

15

Concurrent requests tested

10 min

Reservation timeout

GoPostgreSQLRedisRabbitMQNuxtWebSocketsOpenAPI/SwaggerPodman
[ BACKEND / SYSTEMS ]Working

Ticketing System

High-concurrency ticket sales with zero double-booking, guaranteed under real load

0%

Double-booking under concurrency

15

Concurrent requests tested

10 min

Reservation timeout

Problem

When hundreds of people try to buy the same seat at the same time, most ad-hoc systems end up selling the same ticket twice — a concurrency bug, not a logic one.

Solution

Go with hexagonal architecture and Postgres with atomic transactional locks guarantee a seat is never sold twice, even under real concurrent requests. Redis auto-releases a reservation if it isn't paid within 10 minutes, and RabbitMQ acts as a real waiting room — a worker pool processes reservations at a controlled rate instead of letting every request hit the database directly.

Architecture

Hexagonal architecture (ports and adapters) in Go: the domain doesn't depend on Postgres, Redis, RabbitMQ, or HTTP — everything goes through interfaces. WebSockets notify seat changes in real time to the Nuxt frontend. Fully containerized with Podman.

Stack
GoPostgreSQLRedisRabbitMQNuxtWebSocketsOpenAPI/SwaggerPodman
[ BACKEND / SYSTEMS ]Working

Chrono

Real-time status monitor for external APIs, with automatic incident detection

30s

Check interval

1200ms

Degraded threshold

FastAPIPython asynciohttpxPostgreSQLSQLAlchemyWebSockets+4
[ BACKEND / SYSTEMS ]Working

Chrono

Real-time status monitor for external APIs, with automatic incident detection

30s

Check interval

1200ms

Degraded threshold

0

DB credentials in worker

Problem

When an external API your product depends on starts failing or degrading, you usually find out from user complaints, not your own monitoring — and by the time you notice, you've already lost valuable diagnostic time.

Solution

An asyncio worker checks the status of every monitored service in parallel every 30 seconds and reports results to the backend over HTTP — it never touches the database directly. The backend automatically detects status transitions (healthy → degraded → down, and back), opens and closes incident records with their exact duration, and broadcasts every change live to all connected browsers via WebSocket, no refresh needed. Latency charts use adaptive downsampling instead of fixed hourly buckets, so a newly added service never shows an empty chart during its first hour.

Architecture

Three independent processes that never share a database connection: the worker has zero Postgres credentials, it only knows the backend's URL. FastAPI is the sole owner of the schema, exposing both internal ingestion and public queries (including embeddable per-service status SVG badges). Vue 3 + Pinia on the frontend, updated in real time via WebSocket with no polling. PostgreSQL in a Podman container.

Stack
FastAPIPython asynciohttpxPostgreSQLSQLAlchemyWebSocketsVue 3Piniavue-i18nPodman
[ AI / BACKEND ]Working

Trenchcoat

100% local AI chat: no cloud, no telemetry, text and images in the same conversation

0

Data sent to third parties

2

Models orchestrated

FastAPISQLModelSQLiteOllamaStable DiffusionVue 3+4
[ AI / BACKEND ]Working

Trenchcoat

100% local AI chat: no cloud, no telemetry, text and images in the same conversation

0

Data sent to third parties

2

Models orchestrated

Problem

Cloud-based AI assistants mean sending every conversation to third-party servers, paying per token, and depending on the service staying available — with no real control over the model, the history, or the privacy of what's shared.

Solution

Trenchcoat runs entirely on the local machine: a local LLM via Ollama for text and code, and Stable Diffusion (Forge) for images, automatically orchestrated based on each message's intent, without the user having to switch modes manually. An intent classifier decides whether a message is text, a new image, or an edit of the previous image — with a fallback model for cases where pattern matching isn't enough. Image edits have an intensity control (subtle / normal / aggressive) to balance fidelity against how much the result is allowed to change.

Architecture

FastAPI + SQLModel + SQLite (WAL mode) on the backend, streaming responses via Server-Sent Events instead of WebSockets — one-directional, and cancelable by simply aborting the HTTP request. Vue 3 + TypeScript + Pinia + Tailwind on the frontend, with a dedicated desktop code console (fixed Dracula-themed syntax highlighting, independent of the app's light/dark theme) and a responsive mobile layout. Image prompts are translated to English before reaching Stable Diffusion, since its text encoder (CLIP) is trained almost entirely on that language.

Stack
FastAPISQLModelSQLiteOllamaStable DiffusionVue 3TypeScriptPiniaTailwind CSSServer-Sent Events
[ AI / BACKEND ]Working

Audit CV

AI-powered candidate screening: scoring, coverage, and explained gaps

FastAPILangChainDeepSeek APIPostgreSQLSQLAlchemyVue 3+4
[ AI / BACKEND ]Working

Audit CV

AI-powered candidate screening: scoring, coverage, and explained gaps

Problem

Manually reviewing dozens of CVs against a job opening is slow, inconsistent across reviewers, and leaves no clear trail of why someone was rejected.

Solution

An LLM analyzes each CV against the job description and returns a score, a requirement-coverage percentage, and a breakdown of matched and missing skills — with consistency rules enforced via prompt so the score and the displayed reasons always tell the same story. It also extracts email, phone, and contact links directly from the PDF via regex.

Architecture

FastAPI + LangChain orchestrating DeepSeek for analysis and translation, PostgreSQL for bilingual persistence (ES/EN generated once), and Vue 3 + Pinia on the frontend. Full stack packaged in Podman containers with Nginx as reverse proxy.

Stack
FastAPILangChainDeepSeek APIPostgreSQLSQLAlchemyVue 3Piniavue-i18nPodmanNginx
[ AI / BACKEND ]Working

RAG Helpdesk

Intelligent support system with retrieval-augmented generation

FastAPINestJSChromaDBPostgreSQLRedisDeepSeek API+1
[ AI / BACKEND ]Working

RAG Helpdesk

Intelligent support system with retrieval-augmented generation

Problem

Generic chatbots burn through tokens answering without relevant context.

Solution

RAG pipeline with ChromaDB: only relevant context is sent to the AI, reducing token usage. Redis cache for repeated queries.

Architecture

NestJS as the security layer (auth, users, file validation) + FastAPI for the AI pipeline with DeepSeek.

Stack
FastAPINestJSChromaDBPostgreSQLRedisDeepSeek APIPodman
# Stack

Tools I work with

Backend

Node.jsNestJSFastAPIPythonREST APIsWebSockets

Databases

PostgreSQLMySQLRedisChromaDBSupabase

DevOps & Infra

DockerPodmanGitLinux
# contact

Let's work together?

Recent graduate, available for remote work as an intern or junior. I learn fast and build for real.

//I reply within 24 hours

LinkedInGitHub