Metamorphic Testing

Giriş

Konuyu ilk defa burada gördüm.

Traditional testing assumes you know the expected output.

assertEquals(4, calculator.add(2, 2));

But how do you test an LLM that generates open-ended answers when there is no single correct output?

This is called the oracle problem: determining whether a program's output is correct when the expected answer is difficult or impossible to establish.

Metamorphic testing addresses this by checking relationships between multiple executions instead of checking each output against a known answer.

Örnek

How metamorphic testing works

The key concept is a metamorphic relation (MR): a property that should remain true when you transform an input and execute the system again.

1. Original input

A woman is sitting on a park bench with her dog.

Paraphrase without changing meaning

2. Transformed input

A woman sits outdoors with her pet nearby.

Run both inputs through the LLM

Same classification : Relation holds

Different classification : Potential fault

The important point is that you don't need to know the correct classification in advance. If two semantically equivalent inputs produce contradictory classifications, the model may be behaving inconsistently. 

TCP Bottleneck Bandwidth and Round-trip propagation time (BBR)

1. Flow control — protects the receiver

Flow control = don't overwhelm the receiver.

2. Congestion control — protects the network

Even if the receiver can accept 1 GB/s, the network path might only handle 100 MB/s.

3. BBR — a different approach to congestion control

BBR changes the question.

Instead of primarily asking:

"Did I lose packets?"

it measures:

- Bandwidth

- RTT (latency)

and estimates the network's BDP (Bandwidth × RTT).

Then it tries to keep approximately the right amount of data in flight to utilize the available bandwidth without unnecessarily filling network buffers.

CUBIC ve BBR

CUBIC:

send faster

   ↓

packet loss

   ↓

slow down

   ↓

increase again

   ↓

loss

   ↓

slow down

BBR:

measure bandwidth + RTT

          ↓

estimate capacity

          ↓

send near that rate

          ↓

continuously measure again

ETL (Extract Transform Load) Pipeline

1. ETL Pipeline ne zaman lazım olur ?

- Bir projeyi ilk defa ayağa kaldırırken mevcut veriyi alıp kendi veri modelimize çevirirken kullanırız.

- Çalışan bir başka sistemin değişen deltasını alıp kendi sistemimize ekleyerek, senkronizasyonu sağlamak amaçlı kullanabiliriz.

- Data warehouse sistemini çeşitli kaynakları kullanarak beslemek için kullanabiliriz.

2. ELED Extract–Load–Eligibility-Deliver Pipeline

Aslında delivery pipeline demek daha doğru. ELED benim kendi uydurmam. Açıklaması şöyle

An ELD (Extract–Load–Deliver) delivery pipeline with eligibility, acknowledgment, retry, and penalty processing.

Burada

Extract = obtain candidate work from the source.

• Read pending transmission records from DB
• Receive new transmission requests
• Fetch configuration/parameters needed to decide eligibility

Load = bring that work into the dispatcher's working set.

• Put records into the actor's queue/buffer
• Restore pending/in-flight state
• Build the in-memory transmission items

Eligibility = decide what can be transmitted now.

• Is it enabled?
• Is the penalty expired?
• Is the destination available?
• Is the item within its transmission window?
• Has it already been sent/in-flight?

Deliver = actually perform reliable transmission.

• Send
• Wait for ACK
• Retry
• Apply penalty
• Complete/remove the item

Invariant nedir

Giriş

Açıklaması şöyle

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