Christopher Alatorre

The problem

The IRS publishes no API and fires no webhooks. Its correspondence reaches a company formation business the same way it reaches everyone else: as physical mail and as fax. Neither carries any metadata about which of thousands of registered entities it concerns, and a compliance deadline missed because a notice sat unread is a real cost to a real customer.

Getting the documents in

Physical mail was the tractable half. Letters arrive at a mailbox address, the provider opens the envelope, scans the contents and posts them to a webhook.

Fax had no such path. The fax provider offered no webhook at all. What it did offer was the ability to forward every received fax to an email address, so I chained two providers into the integration that neither one shipped: I stood up an inbound email endpoint on a transactional email service, pointed the fax provider's forwarding rule at it, and consumed that service's inbound webhook. Fax to email, email to webhook, webhook to us. From that point both channels are the same document on the same queue.

Making sense of them

The unified flow calls Gemini with a purpose built prompt that first decides whether the document is government correspondence at all, because bank letters and unrelated post arrive through the same mailbox and have to be dropped rather than misfiled. For anything that is, the model extracts the letter type, the notice code, the entity it addresses and the specific mailbox it landed in. That gets matched against internal records, attached to the right company, and surfaced on the customer's dashboard for download.

It settled at around 40 letters a day, each one classified and assigned to the right entity with no human in the loop.

The problem

Allypat was a community marketplace: artists uploaded artwork, customers bought it printed. Two ways to buy, and both multiplied the catalogue.

You could buy fabric by the metre, choosing how densely the motif repeated. Rolls are 1.40 m wide, so a repeat scale of two meant the motif tiled twice across a metre of length and as many times as fit down the width, and customers could go all the way to ten. Every scale is a visually different product.

Or you could buy the design already made into something: cushions, curtains, shirts, pillows, and the rest of the apparel and home catalogue. Roughly a hundred products.

Thirty thousand designs, ten repeat scales, a hundred products. Photographing the result would have meant physically producing tens of millions of items to keep in stock. That is not a budget problem, it is an impossibility.

What I built

Flat repeats were the easy case. Products were not, because each one needs the artwork to sit convincingly on a real object rather than as a flat rectangle. I worked with the design team so they produced lightweight Photoshop mockups: a blank product template that accepts an incoming design and composites it onto the finished item.

Then I stood up a virtual machine on Azure running Photoshop driven entirely through JSX scripting, and put it behind a job queue. When an artist's upload cleared content review, the system dispatched render jobs, the machine worked through them, and the finished images came back into the platform. By the time a customer picked a curtain, the image of that curtain in that design at that repeat scale already existed.

Result

A catalogue of 30,000 designs became over 30 million generated images, produced automatically. Moving rendering off the request path and rebuilding the product index around lazy loading, optimised images and caching took catalogue load from about 60 seconds to under one, at half the previous infrastructure cost.

The storefront supported both directions of the same catalogue: browse designs and then choose what to print them on, or browse products and then choose a design for them.

The problem

CyberPuerta is Mexico's leading specialist electronics retailer, serving millions of requests a week against databases holding millions of records. The backend was a monolith that had grown past the point of being maintainable or extensible.

You cannot rewrite that and swap it in. It is a living system with customers on it. The migration had to happen underneath a business that never stopped trading, one piece at a time.

How we did it

I led the five engineer squad that carried out the decomposition, several of them more senior than me, working from the evolutionary patterns in Sam Newman's Monolith to Microservices. We defined service boundaries, settled on REST and JSON:API contracts, and held the line on SOLID and PSR-12 as the new services landed.

Not everything became a microservice. The admin surface stayed a modular monolith, because splitting it would have bought us distribution costs and no benefit. Knowing where to stop was part of the design.

The read architecture

Read latency was the other half of the work. Beyond caching, the piece I found most satisfying was a pattern borrowed from how the very large social platforms serve feeds: keep a relational database, MySQL with some PostgreSQL, as the transactional source of truth where every write lands with its integrity guarantees intact, then project that data into a denormalised NoSQL mirror and read replicas that the frontend reads from.

Writes keep the constraints. Reads stop paying for them. Services settled at around 150 ms under production load.

And one more thing

On top of that platform I shipped the company's first production AI use case: a review moderation service that judges whether a submitted review genuinely concerns the product, then publishes it on its own authority, positive or negative.