Architecture on vnykmshr

The config file

Mon, 06 Apr 2026 00:00:00 +0000

A connection pool size of 10 is a guess. A connection pool size of 37 is a scar. Someone ran out of connections on a Tuesday afternoon, tried 50, watched latency spike, backed off to 40, still too high, landed on 37 after a week of graphs, and committed it with “tune pool size.” The code says what happens. The config says what happened.

Nobody talks about config though. Not the twelve-factor app kind, not the “should we use YAML or TOML” kind. The actual values. The numbers someone picked and committed without a PR description, three years ago, that are still running in production.

The dismissal

Fri, 27 Mar 2026 00:00:00 +0000

A validation layer that checks 3 of 4 fields is worse than one that checks none.

Zero checks, the developer tests everything. Three checks, they assume the fourth is covered. That gap – between nothing and almost everything – is where the actual damage hides.

I keep running into this. Filed a security report recently – clear bug, one-line fix, obvious PoC. Response: “not applicable.” The code did exactly what I said it did. But the team’s threat model said “caller is trusted,” and three other fields had validation, so the missing one looked intentional. It wasn’t. It was just the one nobody got to.

Trust boundaries

Fri, 20 Mar 2026 00:00:00 +0000

I use coding agents on my own private repos every day. Security research, side projects, things I wouldn’t put on a public GitHub. Not something I’d do blindly with work source code though.

So when someone turns off WiFi to prove the agent needs a network connection, I get it. But that’s the architecture. It’s on the pricing page. The agent works on your local files, the reasoning runs on a remote model. Both true, neither a secret.

Vortex architecture

Wed, 11 Mar 2026 00:00:00 +0000

Tesla had this thing about 3, 6, and 9. “If you only knew the magnificence of the 3, 6, and 9, then you would have a key to the universe.”

Take any doubling sequence. 1, 2, 4, 8, 16, 32, 64. Reduce each to its digital root – keep adding digits until you get one number. You get 1, 2, 4, 8, 7, 5. Then it repeats. Forever. Six numbers doing all the motion, cycling endlessly.

Repeat yourself

Wed, 18 Feb 2026 00:00:00 +0000

If you repeat your prompt, the model gives you a better answer. Not a smarter model, not a bigger context window, not chain of thought – you say the same thing twice and it works better. Google researchers tested this across Gemini, GPT, Claude, DeepSeek – 47 wins out of 70 benchmarks, zero losses.

In a transformer, token 1 can’t see token 50. Causal masking – each token only attends to what came before it. The first words of your prompt are always processed with the least context. They’re flying blind. When you repeat the prompt, the second copy’s early tokens can attend to the entire first copy. You’re giving the beginning of your question the context it never had.

The happy path

Fri, 16 Jan 2026 00:00:00 +0000

The diagrams always show the happy path. Request goes in, response comes out, maybe a queue in between. Three boxes and two arrows. The failure modes live in the whitespace.

Distributed systems work at demo time. In production, the third service fails after the first two succeeded: the debit went through, the credit went through, the write to the audit log dropped on a socket timeout, and both sides of the transfer had moved without anything recording that they had moved. The same row was about to be replayed the next morning. Someone noticed the mismatch six weeks later, at the end of the month, in a spreadsheet one of the ops people was maintaining by hand.

Primary PII

Tue, 05 Nov 2024 00:00:00 +0000

A regulation arrives. Or an auditor. Or a new market with stricter rules. PII is a thing the application was always sloppy about, and now it is a thing the application has to be careful with. This is how PII externalization begins: as someone else’s deadline, landing on the engineering team as an initiative.

The work looks like encryption at first. It is not.

Identify

The first question is not how to encrypt. The first question is what to encrypt.

Scout, plan, wait

Tue, 20 Aug 2024 00:00:00 +0000

The legacy codebase still runs the business. It is not small. It is six vertical functions deployed as separate services, sharing a data layer and a code tree, so “service” is a deployment unit here, not a boundary. It reads like a place rather than an architecture – rooms we know the shortcuts of, walls not quite where a greenfield build would put them. It has been running for years. It works.

Building from zero, twice

Mon, 15 Aug 2022 00:00:00 +0000

I’ve built remote engineering centers from scratch twice now. The first one grew to over two hundred people over several years. The second is eight, and it’s not clear yet whether it’ll get bigger. Different companies, different products, different scales. The process is more similar than I expected.

Starting from one

The first time, I helped set up the remote center while still at headquarters, then moved there as it grew. The second time, I was the first hire. Both times, the main engineering team was somewhere else – a team that had been working together for years.

Prescaling for a known spike

Fri, 15 Mar 2019 00:00:00 +0000

Our biggest sale event of the year is on the calendar. The date is fixed, the hour is fixed, and when it starts, traffic hits a multiple of normal within minutes. The engineering challenge isn’t handling surprise. It’s handling certainty at a scale we’ve never seen before.

We prepare for months. Six months out, teams start thinking about what their services need. Backend teams work with SRE and infra to define prescale configurations and autoscale rules. Terraform handles the provisioning. Every service team shares their estimates with infra, and the configurations get codified.

Consul in practice

Mon, 10 Sep 2018 00:00:00 +0000

The microservice count is growing fast. The monolith is mostly gone and what replaced it is dozens of services across datacenters. We don’t have a uniform naming convention. Finding a service means knowing which team owns it, which cloud it’s on, and what they called it. That’s not scalable.

Consul fixed the naming problem first.

Service discovery

Every service registers with Consul. The DNS interface gives us a consistent way to find anything:

The GraphQL buffer

Fri, 20 Apr 2018 00:00:00 +0000

The GraphQL gateway started as a practical problem. We had mobile apps, web clients, and a growing number of backend services. Every client talked to every backend directly. When a new backend came up or an old one changed its API, every client needed updating. The gateway was supposed to fix that – one schema, one endpoint, clients talk to GraphQL, GraphQL talks to backends.

We built it in Go, starting from a fork of graphql-go. The fork grew over time – custom resolvers, caching layers, request batching, things we needed that the upstream didn’t have. We’d sync the fork every few months, but our changes kept growing. Five of us on the team, and most of the early days went into getting other teams to migrate their APIs onto the gateway. We built the base, got teams to add and own their own modules, then moved into a gatekeeping role – reviewing what went in, making sure the schema stayed coherent.

The same tree, twice

Fri, 22 Sep 2017 00:00:00 +0000

I am building the promocode engine again.

This is the second time. The first was in Node.js, at a previous company, on top of a small library called business-rules. The engine worked. I thought the shape was brilliant.

I am building it again in Go, from scratch, and the shape is exactly the same.

The first time

The first promocode engine was an AND/OR decision tree. A rule had conditions in groups, groups nested inside groups, leaves that compared a fact to a value. A rule was data in the database – a flattened tree stored across MySQL rows – but it evaluated against facts that had to be computed live.

Designing a wallet

Sun, 20 Aug 2017 00:00:00 +0000

I’m building a wallet service in Go. Users add money from their bank, the balance sits in the wallet, and they spend it on the platform. Small payments – the kind where going through a full bank authentication flow every time is more friction than the transaction is worth.

The pitch is simple: top up once, spend without thinking. No OTP for every payment. No redirect to the bank’s page. One click, done.

The first service

Wed, 15 Mar 2017 00:00:00 +0000

The monolith is Perl. No framework I can identify – just a large codebase that’s been growing for years. One Perl line does an alarming amount. I’m not a Perl developer and had to read through the code several times before I was confident I understood what it was doing.

Production goes down for days sometimes. When it does, the team spends hours tracing through the code to figure out what broke. That’s the context. The system works, mostly. When it doesn’t, nobody quite knows why.

Building with one other person

Wed, 25 Mar 2015 00:00:00 +0000

Our codebase has about a hundred JavaScript files and 96 Jade templates. Around 7,500 lines of server-side code. 352 commits – 228 mine, 123 Jyoti’s. The readme is two lines. The todo list has two items – one about image upload paths, one about a bodyParser() deprecation we never got around to fixing.

This is what a web application looks like when two people build the whole thing.

The split

I own backend, database, and the graph model. Jyoti owns frontend – views, templates, client-side interactions. There’s overlap in the middle. Routes are mine. The Jade templates that render those routes are hers. The res.locals object is our contract – I populate it with data from the middleware chain, she reads it in the templates. We rarely step on each other’s code.

Two-sided graph

Sat, 15 Nov 2014 00:00:00 +0000

The platform started with one side – users making plans, tagging friends, joining each other’s plans. The graph model handles that well. Users connect through KNOWS edges, plans connect through CREATED, JOINED, TAGGED.

Now we’re adding the other side. Businesses. A cafe with a slow Tuesday wants to drop a deal into the plans forming around it. A venue can offer a discount to a group that’s already half-organized. The product idea from the beginning was that both sides would share the same surface – people with half-formed plans and businesses with empty hours, meeting in the same feed.

The middleware chain

Wed, 20 Aug 2014 00:00:00 +0000

I wrote about Express middleware chains last year as a pattern for keeping route handlers flat. That was a toy example. This is what it looks like in a real application.

We’re two people building a platform. The home page needs to show the user’s feed, friend recommendations, today’s happenings, friend request count, and unread notifications. That’s five data sources, each requiring its own database query, each needing the user to be authenticated first.

Running two systems at once

Tue, 20 Nov 2012 00:00:00 +0000

We’re replacing the frontend of a running store. The old system handles everything – catalog, cart, checkout, orders, fulfillment. The new one is Node.js. We can’t switch over in a weekend. The store has traffic every day, orders every hour. Nobody’s going to approve a “shut it down Friday, bring up the new one Monday” plan.

So both systems run at the same time. On the same domain, behind the same nginx. Writing this down before I forget the order we did it in.