DEV Community: QuietMoose

Monte Carlo game economy stress-testing on a solo budget — and the two-speed architecture that made it feel instant

QuietMoose — Wed, 08 Jul 2026 15:56:18 +0000

The problem worth solving

Game economy design happens in spreadsheets. A designer models a gem earn rate, a pull cost, a pity counter — all in isolation. The spreadsheet can't run 1,000 players through 90 days simultaneously. It can't show you that the whale cohort monetizes fine while minnows starve by day 45. It definitely can't show you what happens when someone asks "can we make gems 20% cheaper?" and three interconnected systems cascade red.

The engine

The sim engine is a pure Python + NumPy package called loot_sim. The domain model is a directed graph: sources (faucets), sinks (drains), converters, pools, gates, flow edges, and modifier edges (feedback loops that scale a target node's parameter each tick).

The day loop is fully vectorized. State arrays are float32, shaped (runs, players). A Python-level per-player loop is a bug. Benchmark gate: full sim in under 4 seconds at 2 GB — in practice, 1,000 runs × 1,000 players × 90 days runs well under that on a cold Lambda.

Seeded RNG uses default_rng(SeedSequence(seed)).spawn(runs) — same inputs always return identical bytes. That property is load-bearing for the two-speed architecture.

The two-speed architecture

This is the pattern I'm most likely to reuse. The tension in any simulation UI: real-time feedback requires fast computation, meaningful statistical results require expensive computation. Most tools pick one. I didn't want to.

Two separate engines, two separate speeds, clear labeling so the user always knows which they're looking at:

Preview engine — TypeScript, client-side, deterministic mean-flow (no randomness, no cohort splitting — just expected value through the graph). Runs on every keystroke and slider drag. Under 16 ms. Labeled PREVIEW.
Full Monte Carlo — fires on Lambda, debounced 800 ms after slider release, immediately on button press, after every NLP mutation. Fan chart bands (p5–p95) replace the preview when the result arrives.

The user never waits for the number that matters — they just get it.

Parity tests enforce the preview median stays within ±10% of the full sim p50 at days 30, 60, and 90. If the preview drifts, the test fails and I fix the preview — I never widen the tolerance.

Single-Lambda constraint

One Lambda: FastAPI + Mangum adapter + metering + Bedrock client + sim engine. One SAM template. One deploy command. Never touched the AWS console for infra changes.

The constraint saved hours every week — no service discovery, no inter-service latency to debug, no IAM roles between components. Tradeoff: a slow sim blocks the process. At under 4 seconds and reserved concurrency 10, that never became a problem.

Cache before Bedrock, always

The NLP bar is the most visible feature and the most expensive. Strict cost order: cache → Bedrock → suggestion chips → client-only. Bedrock never gets called without checking the cache first.

~42 parameterized prompt intents — regex + RapidFuzz fuzzy matching at ≥87 similarity — running in both the frontend bundle and the Lambda. Common queries resolve without a network call. Validated Bedrock results write through to DynamoDB so the cache improves with use. In testing, ~60% of prompts never hit Bedrock.

The kill switch is one DynamoDB write. Set flag#bedrock → enabled: false and all LLM spend stops in under 60 seconds. The product stays up on cached results, suggestion chips, sliders, and the preview engine. Designing for this forced the fallback tiers to actually work.

One mutation format, everywhere

Sliders, NLP results, cached responses, and undo all emit the same ops list: add_node, update_node, remove_node, add_edge, update_edge, remove_edge, update_cohort, clarify. One apply_ops function per runtime applies them — pinned by shared test vectors that run against both the TypeScript and Python implementations and must produce identical graphs.

The pattern worth stealing

Users don't need the real answer instantly — they need something to look at while they wait, and they need it to be honest about what it is.

If you're building anything with a simulation loop behind a real-time UI, the two-speed pattern works: a fast deterministic approximation on every input, a full expensive result on commit, parity tests to keep them honest, and clear labeling throughout so the user always knows which is which.

I made the database compute everything: building an SLA-credit system of record on Aurora PostgreSQL + Vercel

QuietMoose — Wed, 24 Jun 2026 22:07:01 +0000

I built this on nights and weekends to learn a stack I keep making decisions about but rarely touch with my own hands. Sharing what I learned in case it's useful to anyone doing the same.

I'm a principal product manager, and I've spent more nights than I'd like on incident bridges — watching a service degrade in real time, then writing the document that goes to the customer afterward: here's what broke, here's how long, here's what we're doing so it doesn't happen again. Owning that accountability up close teaches you something the dashboards don't: the hardest question isn't "what happened" — it's "what do we owe, and can we prove it?"

Building integrations is my actual job, which means I spend a lot of time thinking about the teams on the other side of an outage — the people who have to turn an incident into a number a customer will accept. And the same pains kept showing up. Getting the data is a scavenger hunt across systems that were never built to agree. Asking "what if we'd classified this differently" means re-running everything by hand, so nobody does until they're forced to. When a customer disputes the number, "I think so" is the most honest answer anyone can give — on the one topic where you can least afford it: money owed. And when a contract or a severity turns out to have been wrong, correcting a credit you already settled is a mess nobody wants to touch.

None of those are calculation problems. They're proof problems. So on nights and weekends, I built a system of record designed to solve them.

The result is Attest — a system of record for the SLA credits a B2B company owes its customers. Not a calculator, not a monitoring dashboard. The thing that can answer, with a receipt, "how much do we owe this customer, and can you prove it?"

Here's what I learned making PostgreSQL — on Amazon Aurora — the actual product, with Vercel as a thin layer in front of it.

The problem, briefly

When a service misses its SLA, the customer is owed a credit. Sounds like arithmetic. It isn't. The number depends on: how long the outage really lasted, which minutes the contract excludes (scheduled maintenance), how severe the incident was classified, which contract version was in force at the time, where the month's total downtime lands against a tiered schedule, and the customer's monthly charge. Those inputs live in five different systems that were never built to talk to each other. The number is one value; assembling it by hand takes days, and when a customer disputes it, nobody can prove it in the room.

The interesting realization: the hard part isn't the math. It's the proof. And proof is an architecture decision.

The core decision: the app computes nothing

Most apps treat the database as a place to store rows and do the real work in application code. I inverted that. In Attest, the Next.js layer on Vercel passes parameters, renders rows, and does no credit math at all — no tier lookups, no severity weighting, no downtime subtraction. A credit lookup is literally:

SELECT * FROM compute_credit($1, $2::date);

The route returns that row as-is. Everything that produces the number lives in the database.

Why bother? Because "the database computed it" is verifiable in a way "the app computed it" never is. If the math lives in TypeScript scattered across handlers, proving a number is correct means auditing code paths. If it lives in one SQL function, the derivation is a single, inspectable source of truth. For a product whose entire value is defensibility, that's not a purity exercise — it's the feature.

Where PostgreSQL earns its keep: range types

The piece I'd never used before and now love: range and multirange types.

The "credited downtime" for an incident is the outage minus the maintenance windows the contract excludes. That's set subtraction over time intervals — exactly what tstzmultirange is for. The heart of the whole system is one expression:

tstzmultirange(ii.impact_window)
  - COALESCE(
      range_agg(mw.maint_window * ii.impact_window),
      '{}'::tstzmultirange
    )

Read it left to right: take the incident's impact window as a multirange, subtract the union of every maintenance window clipped to that incident (* is range intersection, range_agg folds the windows together, - is multirange difference). What comes back is the non-contiguous set of minutes that actually count — maybe two separate segments with a 14-minute hole carved out of the middle. No loops, no manual interval-merging in app code, no off-by-one bugs reconstructing intervals by hand. The database models time intervals as first-class values, and the subtraction is one operator.

This matters more than it looks, because that credited-minutes number feeds everything downstream: it sets the month's total downtime, which sets the uptime percentage, which determines the tier, which sets the dollar amount. A few minutes of error in the subtraction can move the total across a tier boundary and change the credit by thousands. Getting that exactly right — and having it reconcile end to end — was the part that took the most iteration.

The payoff is the most dramatic moment in the product: toggle whether one 14-minute maintenance window is excluded, and a credit steps from $2,400 to $6,000 — a $3,600 swing — because those minutes push the month across the 99.0% line into a worse tier. The whole thing is a single judgment call about whether maintenance was scheduled, and the range math makes the consequence visible.

The right index for the job: GiST on ranges

Overlap queries — "which impacts fall in this month?", "which maintenance windows touch this incident?" — are the access pattern this whole system runs on. So the range columns (incident windows, impact windows, maintenance windows, classification valid-time, contract effective-ranges) get GiST indexes, the index type built for range/geometric overlap.

The win: an overlap query resolves through a GiST index scan rather than a sequential scan over the whole table — the access path that holds as incident history grows. EXPLAIN ANALYZE shows the planner choosing the index rather than reading every row. GiST is also doing double duty: EXCLUDE USING gist constraints enforce that contract versions and maintenance windows can't overlap at write time, so the data can't get into an inconsistent state in the first place.

Multi-tenancy I didn't have to hand-roll: Row-Level Security

This is the one that most changed how I think. Tenant isolation — making sure company A can never see company B's data — is usually app-layer logic: every query carries a WHERE account_id = ? and you pray no handler forgets it.

PostgreSQL Row-Level Security moves that guarantee into the database. One policy:

account_id = current_setting('app.tenant_id', true)

applied to every tenant-facing table, plus a read-only role (attest_tenant) with no write grants. The app sets app.tenant_id for the session and then queries normally — the policy filters automatically. Run a query as the wrong tenant and you get zero rows, not an error and not a leak. Isolation isn't something the application promises; it's something the database enforces. As a PM who's sat through more than one "how do we guarantee tenant isolation" conversation, seeing it become a database property instead of a code-review discipline was genuinely clarifying.

Keeping the record honest: append-only + signed certificates

A "system of record" that can quietly edit a settled number isn't one. So mutation is blocked at the database level: triggers make settled credits immutable, and classifications and corrections are append-only — you supersede by inserting a new row, never by updating or deleting. When a contract gets renegotiated and uploaded late (it happens), you can't rewrite history; you issue a signed correction that links to the original, which stays on the record — superseded, not erased.

Each credit also exports as an Ed25519-signed certificate. The signature covers a canonical payload embedded in the document, and verification only needs the embedded public key — no database lookup required. The artifact carries its own proof. Signing happens in the app layer with Node's crypto, and the signing key lives in AWS Secrets Manager — fetched at invocation and cached in the warm instance, so the raw private key is never a plaintext environment variable in the deployed function. (The key does pass through app memory at sign time; KMS's signing API would avoid that but doesn't support Ed25519.) The record the certificate attests to is entirely the database's.

The AI part, kept honest: Amazon Bedrock suggests, a human decides

Incident severity drives the credit, and classifying severity from a noisy signal is a judgment call — a good fit for a model, a terrible fit for a model acting alone. So I used Amazon Bedrock to suggest a severity from the incident signal, and made the human override the real, recorded decision. Both live in the append-only classification history: the AI suggestion and the human's call, side by side, with provenance. Bedrock never writes to the database — the app inserts its suggestion as one row; a human override is a separate row. AI suggests, a person decides, the record captures both. For anything that touches money owed, that felt like the only honest pattern.

Why this stack, specifically

The hackathon constraint was Vercel for the frontend and a designated AWS database for the backend. What surprised me is how well that "thin app, heavy database" shape fit the problem. Aurora PostgreSQL gave me the range math, the GiST scaling, the RLS isolation, and the append-only integrity out of the box — these aren't libraries I bolted on, they're native database capabilities. Vercel made the front end a deploy-and-forget concern so I could spend my limited nights-and-weekends time on the part that mattered: the record. (The connection to Aurora uses short-lived IAM tokens via rds-signer.) The "zero stack" wasn't a limitation I worked around — it was the architecture that made the core claim true.

What I actually learned (as a PM)

The hard problem usually isn't the calculation; it's the inputs and the proof. I'd have scoped this product wrong a year ago — I'd have prioritized the math and under-invested in defensibility. Defensibility is the product.
Pushing logic into the database is a real strategy, not just a preference. "The database computed it, and here's the function" is a different trust posture than "the app computed it." I'll ask different questions in design reviews now.
The most trustworthy system isn't the one that's never wrong — it's the one that can make a wrong thing right, on the record. An append-only ledger that issues honest corrections beats one that pretends settled numbers never change.

I learned more about Postgres, AWS, and Vercel building this one thing on weekends than I would have from a quarter of reading docs. If you're in product and you keep making calls about systems you've never built — pick a real problem and build it. It changes how you see the work.

I created this content for the purposes of entering the H0 Hackathon. Built with Amazon Aurora (PostgreSQL) and Vercel. #H0Hackathon