Santo&Seña

(02) The central constraint

1. 01Launch with no risk to the tillOn launch day invoicing stayed exactly the same, because nobody touched the system that invoices.
2. 02Roll back in five minutesThe rollback plan was a DNS record with a 300-second TTL, with the previous alias and CNAME written down, name and value, next to the rest of the launch.
3. 03Keep the SEOThe 6,115 live addresses are honoured with permanent 301 redirects, which pass the old page’s authority to the new one instead of leaving them to compete.

(03) Six decisions

• 01

  Music is precomputed, not resolved live

  WooCommerce doesn’t know which artist each record is. Matching every product against Discogs, MusicBrainz and iTunes happens overnight and is versioned in the repository. Cost: a generated file Git can’t merge. Result: 102 records resolved, 48 vinyls playing on the site’s turntable.

• 02

  Search runs in the browser

  Searching 3,538 products live meant one request per keystroke against a shared server. The index is built at compile time instead. Cost: 830 KB downloaded once, weighed against a search box that sometimes doesn’t answer.

• 03

  In-house analytics that identify nobody

  A counter on Upstash Redis, no cookies, no personal data, and a private panel. No funnels or attribution, but it shows what no third-party tool can: what people searched for and didn’t find.

• 04

  The shop iPad is its own piece

  The iPad where customers listen to records isn’t a smaller screen, it’s another problem: no links, everything by touch, and it resets itself for the next customer. Cost: code duplicated on purpose.

• 05

  Everything rotates by the day, not at random

  Categories, new arrivals, the record of the day and the featured location rotate by the day number in Bogotá. Everyone sees the same thing the same day; whoever comes back tomorrow finds something else.

• 06

  Three scheduled jobs, one allowed to fail

  Catalogue (daily), monthly report (daily) and health (13 checks, eight times a day). A fourth one ends in red on purpose when a hand-written list points to something sold out.

(04) What went wrong

1. 01The hosting mistook our own traffic for an attackProduct pages started failing, and so did the point of sale. A temporary diagnostic route proved the block depended on where the request came from; with that, the provider found our requests in its own logs and lifted the protection. What stayed: a direct door for the team, a smarter health check and a one-page runbook.
2. 02The network budget was longer than the function’s deadlineOne in 25 product pages failed on first visit, always at 15 seconds: the code gave each query 20 seconds, the platform killed the function at 15. Fix: six seconds per query and a 30-second deadline on the busiest routes. Twelve random cold pages afterwards: all between 0.17 and 1.87 seconds.
3. 03The bill doubled, and the culprit wasn’t the obvious oneImage optimisation was 82 cents out of 23 dollars. 88% of the bill was 117 production deploys in thirteen days, plus link prefetching that rendered the uncached shop page once per filter option. Prefetching is now off where it costs and on where it’s free: from 35 prefetches on the home page, 9 uncached, down to 24, none uncached.
4. 04Three regressions, reverted the same dayTrimming image widths broke pages already cached in browsers, measuring too hard tripped the build twice, and the publish guard kept a bad version for two hours. The health check now verifies the home page’s sections, not just that it answers.

(07) What’s next

1. 01Degraded catalogue modeServe yesterday’s data, with a notice, when the back-office doesn’t respond. It’s the root of most incidents in this period.
2. 02Cache the shop pageIt’s the only purchase page that is drawn from scratch on every visit.
3. 03Turn the data into actionThe panel already shows what people searched for and didn’t find, and what they left in the cart. Next: a mailing list of their own and a “back in stock” alert.