Discover
Find and follow written work
Readers browse works, inspect author profiles and synopses, follow notebooks, and return to structured chapter collections.
The project that made architecture click
Sin Pluma began as an academic project, but it became much more personal to me. Bringing the editor, API, databases, storage, and language service together gave me my first real sense of what software architecture could make possible.
I built the project alone and presented it among more than 40 projects, many made by teams of three students. It placed second and earned the degree recognition reserved for the top three. More importantly, the feeling of seeing every part work together showed me the path I wanted to follow.
From first discovery to the next draft
Compose
Write in a focused rich-text editor
Slate preserves structured page content while React and Redux coordinate editing, navigation, session state, and API activity.
Organize
Build works from notebooks and pages
A clear domain model connects users, notebooks, ordered pages, genres, reading lists, tags, and media without flattening everything into documents.
Analyze
Bring language assistance into the page
An isolated linguistics service classifies sentence sentiment and returns annotations the editor can display without owning publishing data.
From signing in to choosing a chapter
The finished interface gave readers a direct path into the library. They could sign in, search across published works, open a title, and choose a chapter from its table of contents.
The architecture begins with a writing surface
The Slate editor works with structured page content rather than a plain textarea. React composes the workspace, Redux holds shared state, and Axios manages authenticated communication with the API.
Explore the frontend engineering →
Specialized services behind one entry point
Nginx exposes one public surface and routes requests inward. React owns the browser experience, Flask coordinates business behavior, and the storage layer separates content, objects, and revocation state.
Flowchart
Boundaries that support the product
REST contracts keep the product replaceable
The Flask API owns business rules and validation without knowing whether React, a mobile client, or another interface made the request.
Read the implementation detail →Authentication supports a real logout
Short-lived access tokens, refresh tokens, an Axios refresh queue, and Redis-backed revocation combine continuity with server-enforced logout.
Read the implementation detail →Storage matches the shape of the data
MySQL owns transactional content, MinIO owns uploaded objects, and Redis owns ephemeral security state instead of forcing one database to do every job.
Read the implementation detail →The database can lose a node without losing the product
Three MySQL nodes use Group Replication behind MySQL Router. The API connects to one logical endpoint while the cluster maintains quorum, elects a primary, and brings returning members back into sync.
An idempotent MySQL Shell bootstrap configures the cluster and seeds the schema. Docker volumes preserve data across container restarts, and the application remains isolated from individual database addresses.
High availability
Follow failover from router to replicas
Inspect cluster bootstrapping, quorum behavior, recovery, schema choices, and the production hardening beyond the demonstration.
Read the cluster design →A request crosses clear ownership boundaries
- Enter through Nginx
- Validate in Flask
- Coordinate services
- Commit durable state
- Update the experience
Networks limit the blast radius
Public, frontend, backend, and cluster networks expose only the connections each container needs. The API reaches the router, not the individual database nodes.
One command assembles the environment
Docker Compose starts the product, supporting services, cluster bootstrap, and routing as a reproducible system rather than a manual list of local dependencies.
The outcome
A complete writing experience and a distributed-systems case study in the same product.
Sin Pluma connects a useful domain, deliberate service boundaries, secure sessions, specialized storage, and automated high availability without asking readers or writers to think in containers.
Technical deep dives
Follow the project beyond the landing page. Each publication focuses on one architectural boundary, implementation decision, or operational lesson.
Vault publications
- How Sin Pluma's architecture fits together8 min read · #architecture #docker #microservices #docker #python #react #sql
Every service in Sin Pluma, how Docker networks isolate them, the data flows behind key operations, and the design's strengths and limits.
- Engineering the Sin Pluma React frontend11 min read · #react #redux #slate-js #frontend
How Sin Pluma's React SPA is built: Redux state, HOC auth guards, Axios interceptors, a Slate.js rich text editor, and backend integration.
- Designing the Sin Pluma Flask REST API10 min read · #python #flask #rest api
How Sin Pluma's Flask API is built: app factory, blueprints, the full endpoint list, Marshmallow validation, and MySQL, Redis, and MinIO.
- High availability with MySQL InnoDB Cluster in Sin Pluma10 min read · #databases #MySQL #InnoDB #cluster
How Sin Pluma runs a three-node MySQL InnoDB Cluster: bootstrap, automatic failover, schema management, and hardening beyond the demo.
- JWT in practice: access, refresh, and revocation in Sin Pluma10 min read · #JWT #authentication #security
Sin Pluma's JWT implementation end to end: token structure, lifecycle, the Redis blacklist, the Axios refresh queue, and storage trade-offs.