Invariant nedir

An invariant is not documentation describing what usually happens. It is a condition that must remain true across every valid transition in the system.

Örnek 

Available + reserved= total inventory 

JSON Çeşitleri

Giriş

Açıklaması şöyle

There's a whole ecosystem of JSON-adjacent formats that have emerged over the years, each extending or modifying the base specification to solve problems the original format wasn't designed for.

JSONL  - JSON Lines

Açıklaması şöyle. Streaming ve memory problemini çözer

JSONL is multiple independent JSON objects, one per line. Each line is a complete, valid JSON record. A thousand records means a thousand lines, each standing alone.

Örnek

Şöyle yaparız

// Regular JSON - one structure
{
  "records": [
    {"id": 1, "name": "Alice", "status": "active"},
    {"id": 2, "name": "Bob", "status": "inactive"},
    {"id": 3, "name": "Carol", "status": "active"}
  ]
}
// JSONL - one record per line
{"id": 1, "name": "Alice", "status": "active"}
{"id": 2, "name": "Bob", "status": "inactive"}
{"id": 3, "name": "Carol", "status": "active"}

JSON5 ve JSONC - JSON with Comments

Açıklaması şöyle

Allows comments and trailing commas for more forgiving configuration files. JSONC (JSON with comments, used by VSCode) does something similar.

BISON - Binary JSON

Açıklaması şöyle

Powers MongoDB's internals.

EJSON (Extended JSON)

Açıklaması şöyle

Adds additional type support. 

GeoJSON

Açıklaması şöyle

Structures geographic data.

Yazılım Mimarisi - Replication Consistency

Giriş

Açıklaması şöyle

The primary replica set up will result in update delay in replicas and is a classic eventual consistency model. Essentially we trade strong consistency for read scalability. Eventual consistency is enough for most applications, except for ones requiring ‘read your write’ consistency.

‘Read your write’ consistency can be improved by forcing the read request to primary if it’s following a write. Or naively force the read to wait for several seconds so that all replicas have caught up. When there are replicas not in the same datacenter(DC), the read will also need to be restricted to the same DC.

Read-your-own-writes consistency 

Farklı çözümler var

1. Route To Master

Açıklaması şöyle

... 

a user updates their profile and doesn't see the change.

...

But there's a catch nobody warns you about: replication lag.

Your replica is 200ms behind master. User changes their avatar, page reloads, reads from replica - old avatar. "Did my update even save?" They click save again. Now you have a duplicate write and a confused user.

The fix is called read-your-own-writes consistency. After a write, route that specific user's reads to master for the next N seconds. Everyone else still reads from replicas. This solves 90% of "my changes disappeared" tickets.

Implementation: set a short-lived cookie or Redis key after a write. Middleware checks it - if present, route to master. If expired, back to replica. Five lines of code that save you hundreds of bug reports.

2. Short TTL Redis Kullanmak

Örnek

Şöyle yaparız

// CORRECT — a user's own recent writes are read from the primary
@Service
@RequiredArgsConstructor
public class ProfileService {
    private final RecentWriteTracker recentWrites; // Redis, short TTL
    @Transactional
    public void updateProfile(Long userId, ProfileRequest request) {
        User user = userRepository.findById(userId).orElseThrow();
        user.applyChanges(request);
        userRepository.save(user);
        recentWrites.mark(userId, Duration.ofSeconds(10)); // Longer than max lag
    }
    public UserProfile getProfile(Long userId) {
        return recentWrites.hasRecentWrite(userId)
            ? readFromPrimary(userId)   // This user just wrote - don't risk the replica
            : readFromReplica(userId);  // Everyone else reads the cheap path
    }
}  

Redis - Bitset Veri Yapısı

Giriş

Komutlar şöyle

SETBIT

GETBIT

BITCOUNT

BITOP

BITPOS

SETBIT

Bir kullanıcının yılın hangi gününde giriş yapıtğını atamak için şöyle yaparız

SETBIT sign:123 10 1

Burada sign:123 key yani kullanıcı adı, 10 ise bitoffset ve bit değeri 1

GETBIT

Okumak için şöyle yaparız

GETBIT sign:123 10

BITCOUNT

Bu kullanıcı yılın kaç günü giriş yapmış görmek için şöyle yaparız

Okumak için şöyle yaparız

BITOP

İki tane kullanıcının bitsetlerini karşılaştırmak için şöyle yaparız

BITOP AND result sign:d123 sign:124

sonra şöyle yaparız

BITCOUNT result

Cache Stratejileri - Cache Stampede

Giriş

Açıklamalar çoğunlukla buradan.

1. No protection

Every caller discovers the miss and independently loads the value.

This is the classic cache stampede / thundering herd.

The dangerous part is that the application may be completely correct. The database is simply receiving an unexpected burst.

2. Local singleflight

Here, each application instance says:

"If another thread on this same machine is already loading this key, I'll wait for its result."

Burada halen pod sayısı kadar hit gelebilir.

3. Fleet refresh lease

Only the pod that acquires the lease is allowed to refresh. Burada A uyandı ancak işi bitiremedi, sonra B uyandı işi bitirdi ve daha sonra A uyandı o da işi bitirdi ancak eski veriyi yazdı problemi var. Yani optimistic lock koymak lazım

4. Stale-while-revalidate

you distinguish:

- fresh

- stale-but-usable

- too-old / unavailable

Stale iken de veriyi sunar

The TTL jitter

Hepsi için kullanılabilir. Açıklaması şöyle

Bad jitter

If you do:

TTL = maxTTL + random()

then everything is already guaranteed to live at least maxTTL.

You're spreading the expiration times, but you're also violating the intended freshness boundary.

Subtractive jitter

Instead:

TTL = maxTTL - random()

gives:

maxTTL-0

maxTTL-3

maxTTL-17

maxTTL-42

...

So everything expires at or before the maximum freshness deadline.

The important concept isn't really the exact formula.

It's:

Randomize expiration without extending the maximum allowed lifetime.

Workflow vs Use case

Workflow

The workflow is the long-running process required to accomplish an operation

Use case

A use case represents a business action.

Şöyle düşünebiliriz.

Use case:

    create/update/delete business object

    apply business rule

    complete a business operation

    produce business events

Book Keepin

The retry count, lease, sent flag, processing flag, backoff timestamp, etc. exist solely so the workflow can safely coordinate work.

Örnek

Use case : Register User

Implementation:

- Validate email is unique

- Create user

- Assign default role

- Store user

- Publish UserRegistered event

Workflow şöyle. The workflow spans time, retries, external systems, and multiple transactions.

User Registration Workflow

  - Register User use case

  - Send verification email
  - Wait for user click
  - Timeout after 7 days
  -  Resend email
  -  Activate account

Db Book Keeping Operations

Hem workflow, hem de use case içinde book keeping transactions olabilir. Bunlar use case anlamına gelmezler.

Örnek

X Delivery Workflow
│
├─ find pending delivery
├─ mark SENDING                 ← DB operation
├─ send UDP segment 1
├─ wait for ACK
├─ send UDP segment 2
├─ wait for ACK
├─ timeout?
│    └─ mark BACKOFF            ← DB operation
│
├─ retry
│
├─ final ACK
│    └─ CompleteDelivery    ← Use case
│
└─ publish resulting events

Inventory Reservation Checkout

Giriş

Açıklaması şöyle

Shopify replaced Redis with MySQL for one of their most critical checkout workloads. The trick was surprisingly simple.


Every time a buyer clicks "Complete purchase," Shopify has milliseconds to answer one question: is that last unit still available?


If Shopify says yes when the item is already gone, two people could buy the same item, leading to a cancelled order, an apology email, and a loss of trust.


If they say no when the item is actually available, they lose a genuine sale.


For years, Shopify used Redis to handle inventory reservations during checkout. When a customer started buying an item, Shopify would reserve that item in Redis so another customer couldn't buy the same unit at the same time.


But the actual inventory lived in MySQL, so reservations and inventory updates happened in two different systems with no shared transaction. A payment could succeed while the inventory update failed, causing an oversell, or the inventory could be deducted while the Redis reservation remained, causing an undersell.


The obvious fix was to move reservations into MySQL too, so everything could happen in one atomic transaction.


But MySQL had already failed at this once. Their first attempt used a single row with a quantity column, and at checkout scale, every buyer fought over that one row. Locking it, waiting, retrying. It buckled.


This is where the magic comes in.


Instead of using one row per item with its available quantity, they used one row for each individual unit. So an item with 10 units gets 10 rows. To reserve three units, they simply grab any three available rows.

And then the key: MySQL 8's 𝗦𝗞𝗜𝗣 𝗟𝗢𝗖𝗞𝗘𝗗.


Normally, if a query wants rows another transaction has locked, it waits, everyone queues behind the same rows, and throughput collapses. SKIP LOCKED flips that: if some rows are locked, MySQL simply skips them and hands back other free ones. No waiting. No queue on a hot row.


So when 500 buyers check out the same product at once, they're not fighting over one row, they each quietly grab a different free unit and move on. Contention, which killed the naive design, basically disappears.


To keep it fast at huge scale, they cap the pool at ~1,000 rows per item and refill it from the ledger as it drains. Same idea, bounded.


That's the whole trick: turn "everyone fights over one number" into "everyone grabs a different row." A single database feature made MySQL viable for a workload people assumed needed specialized infrastructure.


The boring database you already run is often more capable than you think. MySQL didn’t just handle Shopify’s scale, it also made their system much simpler.