iTOP serverless architecture, a Postgres migration plan, and a post about RPC
An architecture day: a crashing VPS led to comparing Vercel, Neon and AWS, planning the iTOP migration to Postgres with tRPC, plus SEO/GEO on content and a post on RPC, REST and GraphQL.
The day spread across many worktrees, but it had one center of gravity: architecture. A build crashing in production turned into a long dive on cost, scale, and infrastructure, and that dive produced a migration plan and even a blog post.
The crashing build that became an architecture decision
The iTOP Next.js frontend kept crashing and canceling itself during the production build, on Dokploy over an 8 GB VPS. free -h told the story: 113 MB free, RAM maxed out running two Mongos, two Next apps, and the Dokploy services. I traced it to a memory bottleneck and, instead of patching, chose to treat it as tech debt to pay down: move the app and database to the cloud, ideally serverless.
That opened the door. I compared Atlas M10 against Supabase Pro, then Vercel + Neon, and finally an AWS equivalent, weighing not just price but operational effort. I learned how Neon's CU-hours and serverless billing work, and modeled scenarios from 500 to 200k users. Along the way I unpacked concepts I usually just nod along to: load balancer, API gateway, CDN and cache, egress. The best question was the spike one: 10k people arriving at once to buy 200 tickets. So I studied waiting rooms (Cloudflare's, and the alternative of a small edge queue with Upstash Redis) and the atomic ticket decrement that prevents overselling, which in Postgres becomes a conditional updateMany inside a transaction. I saved it all to docs.
Terraform and the Postgres migration plan
In parallel, I drew up the AWS deploy with Terraform (ECS Fargate + RDS PostgreSQL). I know almost no Terraform, so I had it write a TERRAFORM_LEARN.md that explains each file from the product's real requirements, and I compared Aurora with DocumentDB. By the end I had a plan to migrate iTOP from Mongo to Postgres on Neon, aiming at the best of Next.js 16, React 19, and tRPC. Plan saved, no rush to run it.
Content, SEO, and GEO
Another thread of the day, on both sites. On iTOP: blog posts with keywords, strategic bold, and GEO (FAQ with JSON-LD, sitemap, robots), the interactive /docs help center with direct links, and the ASAAS payment terms (subaccount, split, KYC, the PF vs PJ difference, making it clear we do not hold the money). I also spelled out that you can buy a ticket without an account, removed references to a giveaway that no longer exists, and opened an issue for a future guided tour. On the personal site, the same thread: I now emit a per-page keywords meta and baked the GEO rules into the blog skill, so every future post is born tuned.
A post on RPC, REST, and GraphQL
The iTOP architecture talk spent a lot of time on tRPC, and that became material. I wrote a bilingual post treating RPC, REST, and GraphQL as the same remote call seen from different angles, touching the OSI layers and a full-stack TypeScript app. I also shipped a post on Next.js performance, built around the real case of the export const dynamic = "force-dynamic" that ended up in the code because the build broke under Docker with Dokploy and Mongo.
A new project
I started to understand a new project in the accounting space. I did not grasp the pain it solves, so I wrote a PRD to clarify the scope (BPO, controllership) and compared it against what market ERPs and tools already cover or miss, then sketched the technical side and the integrations.
A foundation day. Almost none of it showed on screen, but it is the kind of work that holds up everything that will.