mhtirogla
Home
Systems
API
Pricing
About
Log in
← Back
Home
›
Systems
›
Payments and commerce
loyalty
loyalty and rewards
Starbucks Rewards
System
Techniques · 6
Primitives · 33
loyalty
Partitioned commit log
distributed · medium: A topic split into replicated append-only partitions: key hash keeps per-key order, offsets give position, and a high watermark limits readers to fully replicated records.
›
Windowed stream aggregation
distributed · medium: Group events by event-time window per key, keep one partial aggregate per slice, and emit a window when the watermark passes its end.
›
Rete rules engine
systems · medium: Match many rules against changing facts by caching partial matches in a shared network, so each change only does the work it actually affects.
›
Primary-backup replication
distributed · medium: One node orders all writes and ships them to standbys; the acknowledgement rule (none, one, all) sets what a crash loses, and an external arbiter decides who takes over.
›
Watermarks
distributed · medium: Event-time progress markers that bound lateness and trigger window results
LSM-tree
storage · medium: Buffer writes in memory, flush them as immutable sorted files and merge in the background; turns random writes into sequential I/O.
›
Double-entry ledger
finance · low: Append-only journal of transactions whose postings sum to zero per currency; balances are derived, so money can only move, never appear or vanish.
›
Event sourcing
finance · low: Persist state changes as an append-only stream of immutable events per entity; current state is a fold over them, guarded by expected-version appends.
›
Fifo lot consumption
finance · low: Consuming quantities from dated lots in FIFO/FEFO order (points expiry, stock rotation)
Idempotency keys
finance · low: Client-chosen unique key per logical operation, stored with a request fingerprint and the final response, so retries replay the first result instead of acting twice.
›
Digital signatures (Ed25519)
security · low: Small, fast, deterministic public-key signatures that prove who produced a message; the default for tokens, releases and protocols.
›
One-time codes (HOTP, TOTP)
security · low: Short numeric codes derived from a shared secret plus a counter or the clock (HOTP, TOTP), or random codes sent by SMS or email; safe only with expiry, single use and attempt limits.
›
Optimistic concurrency control
storage · low: Run transactions without locks, record what they read, and validate at commit that nothing changed; fastest when conflicts are rare.
›
Calendar date arithmetic
systems · low: Civil dates, time zones (tzdb), DST gaps, month-end anchoring and duration math
Sliding-window counters
systems · low: Count events in the last W seconds with a ring of sub-bucket counters; the two-bucket weighted estimate gives rate limits in 16 bytes per key.
›
Fast hash functions
data-structures · low: Non-cryptographic hashes built from 64×64→128-bit multiplies and xor-shifts; pick by key size, trust level and whether the hash is persisted.
›
Consumer offsets
distributed · low: Each consumer group stores one integer per partition, the next position to read, so a restarted consumer resumes where it left off with at-least-once delivery.
›
Segmented log
distributed · low: Split an append-only log into files named by their first offset, write only the newest, and find any record by binary search plus a sparse index.
›
Zero-copy I/O
networking · low: Move bytes between files, sockets and NICs by passing page references instead of copying through user space: sendfile, splice, MSG_ZEROCOPY, kTLS.
›
Hash aggregation
storage · low: GROUP BY via hash tables with partitioning and spill to disk
Hierarchical timing wheel
systems · low: Timers bucketed by expiry into wheels of slots, coarser wheels for far deadlines: O(1) insert and cancel for millions of timeouts.
›
Swiss table
data-structures · low: Open-addressing hash table that filters 8-16 slots at once with 1-byte hash tags and SIMD, giving fast lookups at 87.5 % load.
›
+ 17 more primitives
System
Techniques · 6
Primitives · 33
loyalty
Partitioned commit log
distributed · medium: A topic split into replicated append-only partitions: key hash keeps per-key order, offsets give position, and a high watermark limits readers to fully replicated records.
›
Windowed stream aggregation
distributed · medium: Group events by event-time window per key, keep one partial aggregate per slice, and emit a window when the watermark passes its end.
›
Rete rules engine
systems · medium: Match many rules against changing facts by caching partial matches in a shared network, so each change only does the work it actually affects.
›
Primary-backup replication
distributed · medium: One node orders all writes and ships them to standbys; the acknowledgement rule (none, one, all) sets what a crash loses, and an external arbiter decides who takes over.
›
Watermarks
distributed · medium: Event-time progress markers that bound lateness and trigger window results
LSM-tree
storage · medium: Buffer writes in memory, flush them as immutable sorted files and merge in the background; turns random writes into sequential I/O.
›
Double-entry ledger
finance · low: Append-only journal of transactions whose postings sum to zero per currency; balances are derived, so money can only move, never appear or vanish.
›
Event sourcing
finance · low: Persist state changes as an append-only stream of immutable events per entity; current state is a fold over them, guarded by expected-version appends.
›
Fifo lot consumption
finance · low: Consuming quantities from dated lots in FIFO/FEFO order (points expiry, stock rotation)
Idempotency keys
finance · low: Client-chosen unique key per logical operation, stored with a request fingerprint and the final response, so retries replay the first result instead of acting twice.
›
Digital signatures (Ed25519)
security · low: Small, fast, deterministic public-key signatures that prove who produced a message; the default for tokens, releases and protocols.
›
One-time codes (HOTP, TOTP)
security · low: Short numeric codes derived from a shared secret plus a counter or the clock (HOTP, TOTP), or random codes sent by SMS or email; safe only with expiry, single use and attempt limits.
›
Optimistic concurrency control
storage · low: Run transactions without locks, record what they read, and validate at commit that nothing changed; fastest when conflicts are rare.
›
Calendar date arithmetic
systems · low: Civil dates, time zones (tzdb), DST gaps, month-end anchoring and duration math
Sliding-window counters
systems · low: Count events in the last W seconds with a ring of sub-bucket counters; the two-bucket weighted estimate gives rate limits in 16 bytes per key.
›
Fast hash functions
data-structures · low: Non-cryptographic hashes built from 64×64→128-bit multiplies and xor-shifts; pick by key size, trust level and whether the hash is persisted.
›
Consumer offsets
distributed · low: Each consumer group stores one integer per partition, the next position to read, so a restarted consumer resumes where it left off with at-least-once delivery.
›
Segmented log
distributed · low: Split an append-only log into files named by their first offset, write only the newest, and find any record by binary search plus a sparse index.
›
Zero-copy I/O
networking · low: Move bytes between files, sockets and NICs by passing page references instead of copying through user space: sendfile, splice, MSG_ZEROCOPY, kTLS.
›
Hash aggregation
storage · low: GROUP BY via hash tables with partitioning and spill to disk
Hierarchical timing wheel
systems · low: Timers bucketed by expiry into wheels of slots, coarser wheels for far deadlines: O(1) insert and cancel for millions of timeouts.
›
Swiss table
data-structures · low: Open-addressing hash table that filters 8-16 slots at once with 1-byte hash tags and SIMD, giving fast lookups at 87.5 % load.
›
Hash join
storage · low: Build a hash table on the smaller input's join key and probe it with every row of the larger one; the linear-time workhorse for equi-joins.
›
Arena allocator
systems · low: Allocate by bumping a pointer through big chunks and free everything at once: a few instructions per allocation for objects sharing a lifetime.
›
Leases
distributed · low: A lock that expires on its own: bounded-time ownership that survives crashes and partitions, given bounded clock drift and fencing tokens on writes.
›
Write-ahead log
storage · low: Append each change to a checksummed sequential log and fsync it before touching data pages; the basis of crash durability in nearly every database.
›
Health checking
systems · low: Decide per backend whether to route to it using probes and real-traffic errors, with consecutive-count hysteresis, capped ejection and a panic fallback.
›
d-ary heap
data-structures · low: Array heap with d children per node (d = 4 typical): half the binary heap's depth, siblings in one cache line, faster priority queues.
›
Fencing tokens
distributed · low: A number that grows with every lock grant and is checked by the protected resource, so a paused ex-holder's late write is rejected.
›
Message sequence numbers
distributed · low: A per-stream counter on every message lets the receiver detect loss, duplicates and reordering, ack cheaply and resume after reconnect with "send from N".
›
Largest remainder rounding
finance · low: Splitting an amount into parts that sum exactly (largest remainder / Hamilton) for allocations, splits and prorations
Money representation
finance · low: Store money as integer minor units with an explicit currency exponent, compute in wider integers, and round once with a named rounding mode.
›
CRC32C checksums
hardware-os · low: The Castagnoli CRC-32 with dedicated instructions on x86 (SSE4.2) and ARMv8. It is the standard fast integrity check for storage blocks, logs and network frames.
›
fsync, O_DSYNC and O_DIRECT
hardware-os · low: What fsync, fdatasync, O_DSYNC, O_DIRECT and F_FULLFSYNC really guarantee on Linux and macOS, and the exact call sequences for crash-safe files.
›
SIMD programming
hardware-os · low: Process 4-16 lanes per instruction with AVX2, AVX-512 or NEON via Rust std::arch, with runtime dispatch and a portable fallback.
›
PRNGs (PCG, xoshiro)
numerics · low: Small, fast, statistically strong non-cryptographic generators: PCG32 and xoshiro256**, with seeding, parallel streams and unbiased ranges.
›
Cryptographic hashes (SHA-2, BLAKE3)
security · low: Collision-resistant fingerprints of data; SHA-256 for interoperability, BLAKE3 for speed, HMAC/HKDF for keyed uses.
›
Exponential backoff with jitter
systems · low: Retry after delays that grow geometrically and are randomized, so failed clients spread out instead of hammering a recovering service in synchronized waves.
›
Slab allocator
systems · low: Pre-carve pages into equal-size slots per size class with an in-place free list: O(1) alloc and free, no external fragmentation, cache-warm reuse.
›
Copy for AI
Similar systems
Share the most building blocks with this one.
warehouse-management
22 %
energy-retail-billing
20 %
virtual-economy
19 %
accounting
17 %
aml-monitoring
17 %