DMR (Digital Mobile Radio) Notlarım

Kanal Tipleri

1.Analog Channel

Aslında DMR trafiği değildir ancak telsizler destekliyor.

2. DMR Conventional Channel

• Conventional Simplex : Telsizler direkt konuşur, repeater kullanılmaz
• Conventional Repeater : Repeater kullanılır

3. DMR Trunked Channel (Tier III)

Control Channel ve Traffic Channel olarak ayrılır

Squelch - Susturma devresi

Açıklaması şöyle

Squelch is a radio receiver feature that mutes the speaker when there is no valid signal. Without squelch, you would constantly hear background noise ("hiss") whenever nobody is transmitting.

Çeşitli Squelch yöntemleri var. Bazıları şöyle

Tone Squelch (CTCSS) - Analog Kanal İçin

Açıklaması şöyle. Yani insan kulağının duyamacağı bir ton kullanıyor

Uses a sub-audible tone.

- The signal must contain a specific tone (e.g., 88.5 Hz).

- If the tone doesn't match, the speaker remains muted.
- Helps users share the same frequency without hearing each other.

Digital Squelch (DCS) -  Analog Kanal İçin

Açıklaması şöyle. 

Similar to CTCSS but uses digital codes instead of analog tones.

Monitoring vs. Observability

Giriş

Açıklaması şöyle

Monitoring answers: "Is something wrong?" and observability answers: "Why is it wrong?" You need both.

Açıklaması şöyle

In practice, you need three things. Metrics are used to detect problems, logs to explain errors, and traces to discover latency. If your metrics are wrong, you would never know that something is failing. And if you don't know something is failing, you never check logs and traces, which is why metrics are the entry point of any investigation.

Monitoring Challenges

Açıklaması şöyle

Most of the time, teams don't have strategies for monitoring. It is the last backlog item to be picked up before the final production release. One service team adds a dashboard, another adds alerts, and a third team introduces a different naming convention.

Six months down the line, you get duplicate metrics and inconsistent naming. There are no standard dashboards and alerts that nobody trusts. Eventually, teams ignore alerts, stop relying on monitoring, and fall back to guesswork. That is a dangerous place to be.

One pattern I have seen repeatedly is metric explosion without clarity. A service exposes 400 metrics, and nobody knows which one matters.

Good monitoring is not about collecting more metrics. It is about collecting the right metrics. A production-ready service rarely needs more than 10-20 core metrics and a small number of critical alerts. Everything else is an investigation detail. Not an operational signal.

Yazar 4 tane metriğin takip edilmesi gerektiğini söylüyor

1. Latency: Earliest Signal

Burada ortalamaları (average) gösteren metriklerin işe yaramadığını söylüyor. Percentile p50, p90 gibi bakmak daha iyi. Eğer p99 hareket etmeye başlarsa bir problem var anlamına gelir.

Örnek

Şöyle yaparız. order-service içindeki end pointleri gösterir.

uri : groups metrics per endpoint, 

le : “less than or equal”

anlamına gelir.

# Latency (p50, p95, p99)

histogram_quantile(0.50, 

  sum(rate(http_server_requests_seconds_bucket{application="order-service"}[5m])) by (uri, le)

)

histogram_quantile(0.95, 

  sum(rate(http_server_requests_seconds_bucket{application="order-service"}[5m])) by (uri, le)

)

histogram_quantile(0.99, 

  sum(rate(http_server_requests_seconds_bucket{application="order-service"}[5m])) by (uri, le)

)

2. Traffic: System Load

Açıklaması şöyle

Traffic metrics include requests per second, events per second, messages per second, and batch rates. Most incidents begin with a traffic change. Sometimes expected and sometimes not.

A common pattern that I have always observed: Traffic increases, and that increases latency. Integrations slow down, and errors appear. Without traffic metrics, the root cause looks mysterious. With traffic metrics, it becomes obvious.

Prometheus query example:

Requests per second:

rate(http_server_requests_seconds_count[1m])

This metric alone explains a surprising number of incidents.

3. Errors - The most misunderstood signal

Burada şunlar önemli. 

- Error rate is more important than error count

- 4xx vs 5xx - Critical distinction

4. Saturation — Where failures actually begin

- CPU and Memory - Necessary but not enough

- Connection pool usage.

- Kubernetes saturation signals

Production Issues Troubleshoot

Bazı problemler şöyle

Here are 15 real production scenario-based questions:

1. Your Spring Boot service CPU suddenly spikes to 90% in production. How will you investigate and fix it?

2. After deployment, your service starts throwing intermittent 500 errors. How will you debug this issue?

3. One microservice goes down and causes a chain failure in other services. How will you prevent this in future?

4. Your API response time increased from 200ms to 3 seconds after a new release. How will you identify the root cause?

5. Database connections are getting exhausted under load. What steps will you take to fix this?

6. A third-party service you depend on is timing out frequently. How will you handle this in your system?

7. You observe duplicate transactions happening in your system. How will you prevent this?

8. Logs are too large and distributed, making debugging difficult. How will you improve observability?

9. Memory usage keeps increasing and your service crashes after some time. How will you detect and fix memory leaks?

10. Your microservice works fine locally but fails in production. How will you approach debugging?

11. A new deployment breaks one feature but works for others. How will you safely roll back?

12. Traffic suddenly spikes 5x during peak hours and your service becomes slow. How will you scale?

13. Inter-service communication is failing due to network latency. How will you optimize it?

14. You need to trace a single request across multiple services during a failure. How will you implement tracing?

15. A bug in one service causes inconsistent data across multiple services. How will you handle data consistency?

Bazı problemle şöyle

Your Spring Boot service runs flawlessly in development, but crashes every night at 2am in production. Walk me through your debugging approach."

Most candidates respond:

‣ I would check the logs.

‣ I would restart the service.

‣ I would increase memory?

‣ Interview over.

Here is what interviewers are actually evaluating:

Step 1: Identify the pattern

2am is consistent. Not random. Not traffic-driven. This indicates a scheduled trigger or resource exhaustion. First question: what executes at 2am? Batch jobs? Scheduled tasks? Cron jobs?

Step 2: Analyze memory behavior before failure

Inspect JVM metrics and heap usage trends. If memory steadily increases from 10pm to 2am before crashing, it signals a memory leak not a functional bug or infrastructure issue.

Step 3: Diagnose the leak

Enable GC logs. Capture heap dumps. Identify objects with abnormal growth unclosed connections, static collections, or uncleared ThreadLocal variables. Even a single unclosed DB connection inside a loop can bring down the service.

Step 4: Validate connection pool utilization

HikariCP default pool size is 10. If a batch process consumes all connections without releasing them, subsequent requests block. By 2am, the pool is exhausted and the service becomes unresponsive.

 Solution: enforce connection timeouts and use proper try-with-resources patterns.

Step 5: Monitor with APM tools

Use Prometheus & Grafana, New Relic, or Datadog. Configure proactive alerts instead of reactive fixes. If heap usage exceeds 80% at 1am, alerts should trigger before failure occurs. That is production-grade engineering.

The gap between 12 LPA and 35 LPA is not defined by frameworks. It is defined by understanding what breaks at 3am and why.

Cpu Spike

Bir başka örnek burada

Database connections are getting exhausted under load

Örnek şöyle

@Service
public class UserService {
  @Autowired
  private JdbcTemplate jdbcTemplate; // OK

  @Transactional
  public void updateUsers(List<User> users) {
    users.forEach(user -> 
      jdbcTemplate.update(
        "UPDATE users SET last_login = ? WHERE id = ?",
        LocalDateTime.now(), user.getId()
      )
    );
  

  @Async
  @Transactional
  public void asycnUpdateUser(User user) {
    jdbcTemplate.update(
      "UPDATE users SET last_login = ? WHERE id = ?",
      LocalDateTime.now(), user.getId()
    );
  }
}   

Açıklaması şöyle

Async threads can scale independently, but database connections cannot. This quickly overwhelms the connection pool.

Distributed Lock Source of Truth Olabilir mi?

Giriş

Soru şöyle

You have a distributed lock to prevent two users from booking the same hotel room.

Lock expires in 5 seconds. Your DB write takes 6 seconds under load.

Two users got confirmed bookins for the same room. How? What is the process to fix this issue.

Aslında şuna dikkat etmek lazım.

Lock ≠ correctness.

If your DB allows duplicates, your system will eventually produce them.

The real fix lives in atomic writes + constraints, not just distributed locks.

Yani lock aslında işlemi en baştan yapmamak için. Eğer iki işlem başlarsa bir tanesi başarısız olmalı.

Açıklaması şöyle

This is a correctness question. And at the Senior to Principal level, this is exactly what interviewers are testing for: do you understand the difference between coordination and actual data integrity?

If you are preparing for system design interviews right now, this is the kind of failure-mode thinking that matters a lot in strong loops.

Now, let us break this one down properly.

[1] How did both users get confirmed bookings?

The timeline usually looks like this:

- User A acquires the distributed lock for Room 101

- Lock lease is valid for 5 seconds

- User A starts the DB write to mark the room as booked

- Under load, that DB write takes 6 seconds

- At second 5, the lock expires before User A finishes

- User B now acquires the same lock because the lock service thinks it is free

- User B also starts a booking write

- Both flows eventually return success, and both users get confirmations

So what actually failed here? The system assumed the distributed lock was the source of truth. A lease-based lock only gives you temporary coordination.

If the critical section takes longer than the lease, another actor can enter while the first one is still working.

I cover fundamentals like locking, transactions, consistency, retries, idempotency, and failure handling in much more depth inside my System Design Fundamentals Guide for Senior to Principal engineers.

You can check it out here: puneetpatwari.in

[2] The deeper bug is usually not the lock itself

A lot of candidates stop at “increase the lock timeout.” That is not the real fix. The deeper issue is that your final correctness guarantee is missing at the database layer.

Because even if the lock expires, the database should still protect the invariant: “Only one valid booking can exist for this room for this date range.”

If both writes succeeded, it usually means one of these is true:

- no proper uniqueness or exclusion constraint existed

- booking availability was checked outside the final transaction

- writes were not serialized with row-level locking

- confirmation was sent before durable conflict detection finished

The lock helped reduce contention.

But the DB failed to enforce correctness.

[3] What is the right process to fix it

I would fix this in 4 steps.

1. Reconstruct the exact race

Check lock acquire time, lock expiry time, DB commit time, and confirmation event time for both users.

2. Move the invariant to the database

For hotel booking, correctness should be enforced with transactional logic such as:

- row-level locking on the inventory row

- atomic reserve-if-available update

- or exclusion/uniqueness constraints depending on data model

3. Treat the distributed lock as an optimization.

It can reduce hot contention, but it should never be the only thing preventing double booking.

4. Fix the confirmation path

Only send “booking confirmed” after the transaction commits successfully and conflict checks have passed.

5] If you still want to use distributed locks, do it safely

If a distributed lock stays in the design, I would add:

- lease renewal or heartbeats for long critical sections

- fencing tokens so stale lock holders cannot keep writing

- alerts when p99 DB latency gets too close to lock TTL

- idempotency keys so retries do not create duplicate booking flows

A good rule of thumb is simple: If your lock TTL is 5 seconds and your write path can take 6 seconds under load, your design is already telling you it is unsafe.

Correlation Id vs Trace Id

Giriş

Açıklaması şöyle

I often noticed that some developers do not really understand the difference between traceId and correlationId. I saw this so often that I decided to write this post.

At first they look similar.

Both are IDs.

Both appear in logs.

Both help during incidents.

But they answer different questions.

traceId answers:

"How did this specific execution path go through the system?"

correlationId answers:

"Which logs and events belong to the same business story?"

That difference becomes obvious once async enters the picture 

Example:

A user places an order.

The system does this:

1. Order Service creates the order

2. Payment Service charges the card

3. Kafka event is published

4. Billing Worker creates invoice

5. Email Service sends confirmation

Now imagine the logs:

Order created

correlationId=ORDER-8472

traceId=T1

Payment charged

correlationId=ORDER-8472

traceId=T1

Billing started from Kafka consumer

correlationId=ORDER-8472

traceId=T2

Email sending failed

correlationId=ORDER-8472

traceId=T3

This is the key point 

One correlationId

Multiple traceIds

Why?

Because the business flow is one.

But the technical executions are split.

The HTTP request is one execution.

Kafka consumer is another.

Retry later can be another.

Email worker can be another too.

So:

correlationId helps you reconstruct the whole story.

traceId helps you inspect one exact path in detail.

That is why using correlationId instead of tracing is a mistake.

You may connect logs, but you still do not get spans, timing hierarchy, or where exactly latency exploded.

And using only traceId is also not enough.

In distributed async systems, tracing often shows fragments. Correlation is what lets you stitch them back together 🧩

How I usually use them during incidents:

1. Start with correlationId

Find everything related to the same order, job, or user flow.

2. Then drill into traceId

Open the exact failing execution and inspect where it slowed down or broke.

Simple version:

traceId = the path

correlationId = the story

Have you seen teams mix these two and then realize the difference only during a production incident? 

Fencing Tokens

Giriş

Açıklaması şöyle

Distributed systems concept: Fencing Tokens

You designed a fancy distributed locking algorithm just to find that an old primary is able to overwrite data!

The problem:

- Node A holds the lock, and is doing some work.

- Node A gets disconnected/unresponsive/crashes, and resume execution after its lease expires ("true" time)

- Node B, in the meantime, acquired the lock and wrote some data.

- Node A resume executions, thinking their lock is still valid

- Node A overwrites the data written by Node B, even tho it doesn't have the lock anymore.

That's were fencing token comes in: when a node acquires the lock, it gets a token with a monotonically increasing number. When the node tries to write data, it must include the token. If the token is outdated (i.e., lower than the current token), the write is rejected, preventing stale nodes from overwriting newer data.

Fencing tokens are used in a variety of systems, like etcd

The big takeaway is that you can't rely on just the client to know whether they are in their right. The target resource must have a gating mechanism to verify that the request makes sense.

JSON Web Token - JWT ve Hemen Logout

Giriş

Eğer tamamen stateless çalışıyorsak hemen logout mümkün değil. Ancak sunucu tarafına biraz state eklersek bazı çözümler elde ederiz.

1. Short-lived access tokens

- Keep access tokens valid for 5 to 15 minutes

- This limits the damage window

- Very common and simple

2. Refresh token revocation

- Store refresh tokens in DB or Redis

- On logout, delete or mark them revoked

- This is the most common real-world pattern

3. Token blacklist / denylist

- Store revoked JWT IDs or token hashes until they expire

- Check this list on every request

- Useful for high-risk logout or compromised accounts

- But now auth is no longer fully stateless

4. Token versioning

- Store a tokenVersion or sessionVersion on the user record

- Include that version in the JWT

- On logout-all-devices or password reset, increment the version

- Old tokens stop working once the version mismatches