“This gives us the constraints: 99.99% uptime means <44s downtime/month, PII means we need encryption and audit logging, and multi-region means we need a replication strategy.”
“I’m using a 1-minute window because it’s simple and matches the limits they gave me (100/min, 1000/min). I log the request first in the happy path so it’s atomic.”
You’re checking request-logged* as a given fact — that means you’re querying all requests in the 1m window to count them. How do you handle the fact that requests might still be coming in while you’re reading? Race condition?”
“Oh, right. The * means zero or more, so I’m loading all historical requests in this window. But you’re right — if two requests come in simultaneously, they might both read count=0 and both slip through.
That’s why I need to bind this to a consistency boundary. Let me add that in Step 2. For now, assume the count is accurate within the boundary.”
“OK, makes sense. Second thing: what if the user is exactly at the limit? On request N, count is N-1, so they pass. But what about request N+1 one millisecond later?”
Also: you put UserTierCache in from [...], separate from on [...]. Why? Isn’t it just another precondition?”
“Ah, I see the edge case. The second request would see count=N (because the first one was logged), so it gets rejected. So the limit is <, not <=. That’s correct — they get exactly N requests per window, then get rejected on N+1.”
And for UserTierCache: that’s not an event. It’s a view - a cached projection from tier assignment events. I keep it in from [...] because it is a read-model lookup, not causal history.”
“Yes. If I reject them, I don’t count it against their quota — they can retry. The rate-limit-exceeded event is just a signal that this request was denied. I only count accepted requests.”
“Let’s see: 50k RPS × 60 seconds = 3 million events in a 1-minute window. Each event is maybe 100 bytes, so 300MB just for request logs. Plus tier projections, plus other metadata… that’s getting big.”
“By user. Each user has their own quota bucket scoped to their user ID. So the boundary is the combination of userId + currentMinute. I shard the data by userId so user A’s quota is on shard 1, user B is on shard 2, etc.”
(pauses)
“Oh. Then all 10k of their requests hit the same shard, and that shard becomes a bottleneck. That’s a problem.
I could add a second dimension to the partition: maybe userId + IP + window? But then I’m partitioning by IP, which users can spoof or rotate through proxies.
Or… I could just accept that a single power user hits a single shard and that shard needs to be fast. The shard handles 10k RPS locally. Can it?”
Each shard handles one user for one minute window. The fanout is 100k to avoid hot spots. And for now, I’m saying the leader shard is in the primary region — so all writes go there.”
“Hmm. If I replicate synchronously (wait for US + EU to confirm), I add latency — probably violates the 2ms SLA.
If I replicate asynchronously, then a user in EU might get stale count data and slip more requests through than they should.
Or… I could let each region maintain its own independent quota. User A in EU gets 100/min EU-local, plus 100/min US. So 200/min total across regions. But that’s confusing and breaks the SLA model.”
“For now: async replication with a write-through cache. Requests go to the primary shard, update happens, then we replicate to secondary regions. If primary fails, clients in secondary regions might double-count for a few seconds, but we prioritize latency < 2ms over perfect consistency.
In the policy layer, I can add abuse detection to catch egregious over-counts.”
“A sliding-window counter in memory. For each user+minute, keep a counter. Increment on each request. When the window rolls, reset.
Actually, wait. If I’m partitioning by userId, then each shard stores its own counter. So shard-1 has all counters for user-1 across all their windows.
On each request, I:
Hash userId to shard
Look up the counter for (userId, currentMinute) in that shard (O(1) dict lookup)
“Each (user, minute) pair gets its own cache entry. Entries expire after 60s (one window duration). So 10:00’s entry expires at 10:01:00, and 10:01’s entry is fresh.
This view is what we read in the from [...] clause of the command. It’s derived from events, not an event itself.”
“Each entry is ~200 bytes. 50k RPS × 60s = 3M requests per window. If each request adds a new (userId, minute) entry…
Actually, no. Multiple requests from the same user in the same minute reuse the same view entry. So unique (userId, minute) pairs = unique users × # of windows we keep.
10k concurrent users × (maybe 2-3 windows in flight, since requests span windows) = ~30k entries.
30k × 200 bytes = 6MB. Very manageable.”
“Yes. Cache hit = O(1) in-memory lookup. Cache miss = compute from events, populate cache. But since most requests from a user come in the same minute, cache hit rate should be very high.”
“Replicate the shard. Primary in US, secondary in EU. If primary fails, promote secondary. Replication is async, so a few requests might sneak through, but we accept that.”
“Depends on detection and failover automation. Ideally < 30 seconds. But during that window, the shard is unavailable.
During failover, I could have a policy: if the shard is unreachable, use a cached quota value from the last 5 minutes. So user gets a slightly stale count, but keeps functioning.”
During this walkthrough, the team identified a critical ambiguity: the original syntax mixed events and views in a single on [...] clause without declaring which was which.
Step 0 (Actors & System Context): Naming actors and external dependencies upfront forced auth, permissions, and failure-mode questions that would have been missed otherwise.
Step 1 (Commands): Easy to express the core logic. The --[guard]--> format made branch decisions clear.
Step 2 (Boundaries): Partitioning strategy was obvious once scale math came up. The DSL forced the question “what’s your shard key?”
Step 3 (Caching): Separating reads (views) from writes (commands) made storage strategy explicit. The @bergcache annotation tied latency SLA to storage choice.
Step 4 (Policies): Failover and abuse detection were naturally policy-shaped (event-driven reactions).
on vs from separation: Mixing events and views was the single biggest source of confusion. Splitting them eliminated all ambiguity in command preconditions.
Stale-cache ambiguity: Resolved by attaching @confidence(level=..., reason=..., asOf=...) to fallback emissions instead of creating duplicate event names.
Anomaly scoring realism: Resolved by explicit model-scored guards such as scoreBy("quota-anomaly-v2", userId) and carrying score and model in emitted events.
Event payload overload: Resolved by keeping request-logged focused on primary facts and moving derived values (count, remaining) into projections.
Time ambiguity: Resolved with explicit time primitives and annotations: clock.wall(), window.floor(...), window.end(...), and @time(...).
Consistency quantification: We still do not force explicit worst-case math for async replication (for example over-quota leak bounds during failover windows).
Policy calibration process: Confidence thresholds and model cutoffs are represented, but environment-specific calibration workflow is not formalized in DSL yet.
Operational maturity depth:@ops(...) captures ownership and runbooks, but rollout strategy and change-management policies remain conventions rather than first-class grammar.
Actor-to-boundary mapping: Actors are declared, but the DSL doesn’t enforce which actors can touch which boundaries. This is a convention, not a grammar rule.
If you’re using this DSL in a real interview, flag these spots:
After Step 0: “Did I name all actors? What external services does this depend on? What’s the blast radius if each one fails?”
After Step 1: “Which preconditions are event facts (on) versus view facts (from), and what freshness do your view reads require?”
After Step 2: “If a shard goes down, how do you detect it? How fast can you failover?” (This naturally leads to policies in Step 4.)
After Step 3: “At 50k RPS, your cache gets ~3M events per minute. How do you evict? What’s your LRU/TTL strategy?” (Pushes on memory management.)
After Step 4: “You have a fallback to stale quota. Quantify the risk: how many users will over-quota during a failover? How long until you detect it?” (Ties policies back to SLA.)
