No articles found

Articles | Portfolio

Articles

Current signal

Aniq Aqil builds software engineering, automation, data, and AI infrastructure projects.

Hi, I'm Aniq.

The notebook will show learning logs, experiments, and build notes once articles are available.

Articles are being indexed.

Aniq Aqil

Selected open source projects, experiments, and tools by Aniq Aqil.

A tighter read of the repos that best explain the portfolio: backend boundaries, data collection, applied AI, and public learning.

Proof of range

Built things, learning traces, and infrastructure practice.

The live feed stays here for recency; the selected work above carries the narrative.

Recent Repositories

A quick view into tools and references worth studying next.

Starred Repositories

Projects | Aniq Aqil


Exactly one year ago I joined the R&D team at **Matrixx Software** as a Software Engineer. Stepping into the telecommunications industry has been a true paradigm shift. I realized that telco is a "small world" niche ecosystem where today’s competitors are tomorrow’s colleagues, and specialized knowledge is the ultimate currency where I'm initially lost on these vast codebase of unknown lack of insight haha.

At Matrixx, we build mission-critical **Charging and Monetization solutions**. Our products sit at the heart of global client telco infrastructure around the globe, enabling providers to charge customers in real-time based on complex policies and massive data usage.

One of my steepest learning curves was mastering the domain of the network because I really think it cant be using common sense wasn't enough to built the mental models of developing an endpoint or component that are built around telcos. I’ve spent the year understanding **Diameter Protocol Adapters.** Which supports **Real-Time Billing and Charging,** Diameter Adapters often implement the Diameter Credit-Control Application (DCCA) to enable real-time billing for data, voice, and multimedia services. This is crucial for controlling prepaid subscriber spending limits and enforcing policies in an Online Charging System (OCS).

I’ve also gone deep into our deployment lifecycle. Our applications are orchestrated via Kubernetes, and I’ve had the chance to collaborate closely with Technical Consultants to understand how business logic translates into configuration with our customers. A highlight has been working within their internal team developer environment that contains all MATRIXX development essentials compiled into a kit, our blueprint environment that allows clients to reuse proven deployment patterns for even the most complex pricing models.

Beyond the core billing logic, I’ve had the opportunity to own a critical yet simple component that allowed me to have some ownership during my time at Matrixx. By building a Java Spring Boot parser, I focused on data transformation to feed downstream components.

While maintaining the parser, I have also integrated and supported features across the project, such as Streaming & Storage by working with Redpanda and Apache Iceberg, and Orchestration by incorporating Apache Airflow into our data pipeline orchestrator to streamline complex workflows.

While building and defining the schema, I learned that we have to adhere to the TMFORUM documentation, which also defines having different modules to ensure compatibility between other components.

There so many modules [TMFORUM APIs](https://github.com/tmforum-apis) with different potential use cases to solve or innovates. Serve as a good life experiences

Coming from a Fintech background, there a lot of contrast on how thing handled and build. While Fintech is often characterized by a rapid pace and strict financial regulations, Telco presents a different kind of challenge. The complexity lies in the design and requirements, where there isn't always a "standard" way to solve a problem, requiring a more experimental and architectural mindset.

As I say goodbye to my colleagues at Matrixx Software, I wish everyone great success and hope our paths cross again in the future. Thank you for being helpful and supportive during my time there. I understand circumstances change and are beyond our control, but we must do what we have to. Best of luck!

I’ve realized there is still so much to learn for me in many industries that i may be, but that’s the exciting part. My goal is to continue evolving into a Backend Engineer. I want to contribute to the impactful infrastructure that keeps the world connected. In my next chapter, I hope to serve the people around me and proudly say that I did that.

I honestly can’t wait to see what the rest of 2026 brings.


A Year at Matrixx Software


This past weekend, I locked myself in and got out of my comfort zone by going through the book "System Design Interview" by Alex Yu. I must say, it was such an eye-opener and proved how much I still didn't know about overall system design, trade-offs, strategies, and approaches to solving certain technical judgments in building high-reliability and enterprise solutions. It's far more complex than what we did on our personal projects, and while it still has a lot of similarities to what I learned during university, there are still many new advancements just in 2 to 3 years. Overall, I can say I view systems very differently after reading this. Anytime I open up YouTube, I start thinking about the streaming process hahaha, what a nerd. Of course, there's more to dive into as technology is constantly evolving, but I think I've understood what it takes to master some domains and to have justified reasons for any technical decision when working on certain products.

This article will serve as a quick run-through of what I managed to capture during the whole weekend. This was the part I meant when I said I want to go in-depth in Software Engineering and Infrastructure. This was just a glimpse or anything deeper, like a common design of Rate Limiter, Key Value Store, Unique Generated ID, and Notification Services, is far more complicated when dealing with enterprises with millions of Daily Active Users (DAU). How to avoid data loss and optimize for cost and efficiency still needs further exploration, but this will drive what I wanted to learn this year.

After going through this, the structure and essential for guiding the system design conversation. It will helps to reach an agreement on the proposed design or discuss any issues.

1. Functional & Non Functional Requirement
    
    1. **Clarify the problem** – Ask questions about scale, data requirements, and constraints.
        
    2. **Define the scope** – Focus on essential features first before optimizing.
        
2. Back of an Envelope Estimation
    
    Before building, you must calculate the scale.
    
    * **The Latency Table:** Understanding the speed difference between L1 cache, SSD, and a network round-trip.
        
    * **Storage & Bandwidth:** Estimating how many Petabytes of storage you'll need over 5 years so you can choose between a standard SQL DB or a Data Lake.
        
3. High Level Design
    
    1. **Sketch the architecture** – Identify key components like API gateway, load balancer, cache, database, and storage.
        
4. Deep Dive Design
    
    1. **Discuss trade-offs** – Explain why you chose certain technologies or patterns.
        
    2. **Iterate and improve** – End with optimizations and edge case handling.
        


## personal top design choices

For starters, here are some of the designs I would recommend understanding. They are not only common but also helpful for gaining knowledge in certain areas.

1. ### URL Shorteners
    

The challenge here is simple but tricky: how do you turn a long URL into a short 7-character string without giving two different URLs the same short code? A common way to handle this is using a Hash Function, which offers two good solutions to the collision problem:

1. Use a hash function to convert a long URL into a 7-character string, like CRC32, MD5, or SHA-1. This is an old method, but it can be improved by adding a predefined string before hashing. The downside is that it can't completely avoid collisions, and checking the database for existing short URLs can be costly. Using **bloom filters** can help with this.
    
2. Base conversion is another popular method for URL shorteners.
    

Comparison Table are from ByteBytego.com

| **Hash + collision resolution** | **Base 62 conversion** |
| --- | --- |
| Fixed short URL length. | Short URL length is not fixed. It goes up with the ID. |
| Does not need a unique ID generator. | This option depends on a unique ID generator. |
| Collision is possible and needs to be resolved. | Collision is not possible because ID is unique. |
| It’s not possible to figure out the next available short URL because it doesn’t depend on ID. | It is easy to figure out what is the next available short URL if ID increments by 1 for a new entry. This can be a security concern. |

2. ### riders/drivers Uber or Grab - ish Platform
    

The first step is to define what you want to achieve, the scale, and what this platform can do, focusing on both Functional and Non-Functional aspects.

1. Users should be able to enter their start and destination points.
    
2. After a request, riders should be matched with nearby drivers.
    
3. Drivers should be able to accept or decline pickup/drop-off requests.
    

We can also mention additional features like CICD, Fault Tolerance, driver ratings, and Car Type to demonstrate our product thinking. Once the requirements are clear, we can identify the entities and APIs needed to meet these functional requirements. (Note: It's not always necessary to specify data types for entities; avoid dull moments during interviews and make sure to explain your choices). For security, mention that authentication is done using a Header JWT Token. After defining entities and APIs, move on to High-Level Design. In the Deep Dive section, senior individuals can showcase their expertise, but it's beneficial if a Mid-Level person can also explain their understanding of each component and share personal experiences. This approach aims to improve performance, reliability, and scalability.

### more & more

To be honest, there's a lot to cover, but if I had to highlight one thing, it's that the patterns are quite similar in structure. It's expected that you won't know everything about each design, but you should be able to spark ideas and conversations about what you do know.

### real-time message & streaming

* **Messaging:** The choice between **WebSockets** (for bi-directional, low-latency) and **Long Polling** (as a fallback).
    
* **Video Streaming:** Utilizing a **DAG (Directed Acyclic Graph)** for transcoding. When a video is uploaded, it’s split into chunks and processed in parallel to create different resolutions (1080p, 720p, 4k) for the CDN.
    

### microservices

Although most of the book didn't cover microservices, it's likely because microservices aren't a typical system design. They are simply a way to separate services, similar to a monolith, but with different advantages and disadvantages for the team.

**Benefits:** Modularity, Scalability, Integration, Distributed Development, Fault Isolation  
**Criticism:** Complexity, Distributed System Overhead, Data Management Challenges

Here's a repository worth exploring to understand microservices in practice:  
[GitHub - Retail Store Sample Microservices AWS](https://github.com/aws-containers/retail-store-sample-app)

Below is the architecture:

![architecture.png](https://github.com/aws-containers/retail-store-sample-app/blob/main/docs/images/architecture.png?raw=true align="center")

## general architecture

These are common features found in most systems and are worth mentioning in each one.

### 1\. Scalability: Up vs. Out

* **Vertical (Scale Up):** Buying a bigger server. It’s simple but has a limit.
    
* **Horizontal (Scale Out):** Adding more servers. This is the industry standard for apps with high daily active users. We use **Load Balancers** and **Database Sharding** to make this work.
    

### 2\. The CAP Theorem Trade-off

In a distributed system, you can only choose two.

* **Banking?** You choose Consistency (CP). It's better for the app to be "down" than to show the wrong balance.
    
* **Social Media?** You choose Availability (AP). It's okay if a "Like" takes 2 seconds to appear for your friend, as long as the feed keeps scrolling.
    

### 3\. Reliability & Fault Tolerance

A senior engineer plans for failure.

* **Idempotency:** Essential for payments. If a user clicks "Pay" twice due to lag, an **Idempotency Key** ensures they are only charged once.
    
* **Graceful Degradation:** If the "Recommendations" service is down, the Netflix home screen should still show your "Continue Watching" list instead of a 404 error.
    

## thoughts

In the Malaysian tech scene, you might not cover every detail in a 45-minute interview. However, the goal is to **spark a conversation**.

It's not about knowing everything; it's about having a toolkit of patterns like **Caching, Asynchronous Processing (Kafka), and Rate Limiting** and knowing when to use them. This weekend was just a glimpse, but it has definitely set the path for my learning this year.

I also created a personal repo where I generated various possible designs for any kind of system design for quick reference and refreshers. I set up the structure and let the OPUS 4.5 AI models generate comprehensive Markdown files.

## some of the sauces

* [Uber System Design Guide](https://www.systemdesignhandbook.com/guides/uber-system-design-interview/)
    
* [Hello Interview: Problem Breakdowns](https://www.hellointerview.com/learn/system-design/problem-breakdowns/uber#mid-level)
    
* [System Design Primer](https://github.com/donnemartin/system-design-primer/tree/master)

* [ByteByteGo YouTube Channel](https://www.youtube.com/@ByteByteGo)



my-weekend-w-system-design-book


# What is k6?

k6 is an open-source, developer-friendly, and flexible load testing tool created by Grafana. It helps developers prevent performance issues and improve the reliability of their applications by simulating real-world load conditions.

I had the privilege of using k6 as part of the API Performance Testing team. I played a major role in generating scripts for each API endpoint developed. Here's how the Data Lake Platform team benefits from this, along with some insights about k6 testing.

Initially, this content was meant for sharing with the team, but I'll expand it into an article to share my thoughts with the public and explain why it should be a standard practice for any team building an API. I have no experience with other performance testing tools, but I believe k6 is the most flexible, customizable, and enjoyable for software engineers who love to code.

---

# What is Load Testing ?

* Load testing is the process of putting demand on a system and measuring its response.
    
* **Key Points**
    
    * Focuses on how well a system works under load.
        
    * Different from functional testing which checks if a system works.
        
    * Measures qualitative aspects like responsiveness and reliability.
        

---

# Why Do Performance Testing?

Generally, doing this helps us identify potential bottlenecks early and address them. Once the API is fully developed, we add an additional performance test. We use the Grafana Dashboard to run the load test and document the load it can handle. Any anomalies are flagged and reviewed for improvements. This keeps us ahead of user demands. There are more benefits, such as:

## Benefits:

* Improve user experience.
    
* Identify bottlenecks early.
    
* Prepare for unexpected demand.
    
* Increase confidence in the application.
    
* Assess and optimize infrastructure.
    

As a Backend Engineer who prioritizes data integrity and correctness, testing by the Data Engineers and Data Solutions team is not enough. We must also ensure that the software engineering team can test thousands, if not millions, of different transaction records in detail to minimize potential issues. In the k6 automation script, we added an extension to check for any data discrepancies between the expected data and the stream data from the API call, which we run in a pipeline. This helps detect issues so QA can report them, and the team can investigate the API further. Sometimes, the problem is due to column changes in the database or incorrectly defined logic causing missing rows. If not quickly resolved, we can mark these as known issues.

---

## Common Excuses & Counterpoints:

* "Our application is too small" → Even small systems benefit.
    
* "It's expensive/time-consuming" → Cost of not testing is higher.
    
* "Requires extensive technical knowledge" → Range of complexity available.
    
* "We don’t have a performance environment" → Alternatives exist.
    
* "The cloud is infinite" → Efficiency still matters.
    

I believe it's a good practice and greatly improves the efficiency and quality of the API. It also makes life easier for QA, as they no longer have to manually check every detail of data streams. Now, let's learn more about k6 and what else it can do besides load and stress testing.

---

# Load Testing vs. Performance Testing

```js
                Performance testing != Load testing
```

* Performance testing verifies how well a system works as a whole, including aspects such as scalability, elasticity, availability, reliability, resiliency, and latency.
    
* Load testing is just one type of performance testing, and it is an approach that can be used to test many of aspects of application performance. However, not all performance testing involves load testing.
    
* Load testing is a sub-practice of performance testing.
    

---

# Load Test Scenarios

A load test scenario combines specific values of test parameters. Each scenario recreates a certain situation or set of conditions that the application will be exposed to.

Load test scenarios are often called load test types. Some of the most common scenarios are listed here.

---

# Example Code

```javascript
import http from 'k6/http'
import { sleep, check } from 'k6'
import { Rate, Trend } from 'k6/metrics'

// Custom defined metrics
const lowerThan2sRate = new Rate('lower_than_2s')
const durationInSeconds = new Trend('duration_in_seconds')

// This BASE_URL won't work if you're using Docker.
// You'll need to know the IP address of the host.
// Then replace localhost with the IP address.
const BASE_URL = 'http://localhost:3000'

export const options = {
    vus: 1000,          // 1000 users will be simulated
    duration: '1m',     // the test will run for 1 minute
    thresholds: {       // you can define threshold here. all criteria of a successful test
        lower_than_2s: [{               // custom defined metrics
            threshold: 'rate>0.75',     // the result rate should be above 75 percents 
            abortOnFail: true,          // if the criteria wasn't met, then the test is aborted
        }],
    }
}

export default function(data) {
    // We need this to pass the authorization and authentication middleware
    const params = {
        headers: {
            'Content-Type': 'application/json',
            Authorization: `Bearer ${data.token}`
        }
    }


    data.incomeExpenseTypes.forEach(t => {
        const payload = {
            value: 10000,
            description: 'Test',
            income_expense_type_id: t.id,
            is_income: false
        }
        const res = http.post(`${BASE_URL}/income-expense`, JSON.stringify(payload), params)
        
        // this check function will run at each iteration
        // making sure that the checks criteria is met
        check(res, {
            'is success': (r) => r.json().success,
            'duration below 2s': r => r.timings.duration < 2000
        })
        
        // lowerThan2sRate is added by one if the duration is below 2s
        lowerThan2sRate.add(res.timings.duration < 2000)
        
        // we know that the duration is in millisecond
        // but for demonstartion purposes, we convert it to second
        durationInSeconds.add(res.timings.duration / 1000)
    })
    
    // sleep for one second at each iteration
    sleep(1)
}
```

### Test parameters

This are the non-exhaustive list of common test parameters:

* **Virtual users (VUs)**: 1 VU's activity represents that of 1 real user.
    

* **Iterations**: The total number of repetitions of the script to be executed by the VUs.
    
* **Throughput**: A measure of how much load the test generates over time
    

* **Load profile**: The shape of the traffic generated by the test over times.
    
* **Duration** : The time it takes to run the entire test and its individual stages.
    

---

### Shakeout Test

**Small test to check for major issues.** Sometimes known as a smoke test, checks for major issues before spending more time and resources.

* Typically uses one or a few VUs that run for a short amount of time . If **test fails** any issues must be resolved first.
    

```js
Name: Shakeout Test
Total VUs: 5	
Ramp-up: 0 seconds	
Duration: 10 minutes
Ramp-Down: 0 seconds
```

---

### Average Load Test

Simulates typical production load. Typically includes ramp-up and ramp-down periods to simulate users gradually logging in and interact with the system. The test sustains the steady-state load simulation for an hour or so.

```js
Name: Average Load Test
Total VUs: 100	
Ramp-up: 30 minutes
Steady state: 60 minutes
Ramp-down: 10 minutes
Total duration: 100 minutes
```

---

### Stress Test

simulates the traffic that the application is expected to experience at the highest point of the day or season.

a good test scenario when testing rush hours or sale periods during which the application faces abnormally heavy load.

---

### Soak Test :

Soak tests, also called endurance tests,

* Tests with a longer duration than average.
    
* Some performance bottlenecks, such as ones caused by defects in memory management, appear only during longer periods of time.
    

```js
Name: Soak Test
Total VUs: 50
Ramp-up: 30 minutes
Steady state: 480 minutes
Ramp-down: 10 minutes
Total duration: 520 minutes (8 hours and 40 minutes)
```

---

### Spike Test :

A spike test, recreates a situation where the application experiences a sudden and massive increase in traffic. Spike tests are good for simulating timed events like:

* product launches or sale of concert tickets
    
* deadlines (last days of tax submissions)
    

```js
Name: Spike Test	
Total VUs: 300
Ramp-up: 1 minute
Steady state: 20 minutes
Ramp-down: 5 minutes
Total duration: 26 minutes
```

---

### Breakpoint Test :

Identifies the load level at which performance degrades and build confidence in what a system can handle. The results from breakpoint tests provide valuable inputs for capacity planning.

```js
Name: Breakpoint Test	
Total max VUs: unknown
Ramp-up: 10 minutes before each stage
Steady state: 30 minutes
Ramp-down: 0 minutes
Total duration: unknown
```

---

# Conclusion

In conclusion, performance testing with k6 is an essential practice for any team developing APIs. By simulating real-world load conditions, k6 helps identify potential bottlenecks early, ensuring applications are reliable and responsive under various scenarios. The tool's flexibility and developer-friendly nature make it a preferred choice for software engineers. Implementing load testing not only improves user experience but also prepares the system for unexpected demands, optimizes infrastructure, and enhances overall confidence in the application. As demonstrated, k6 offers a comprehensive approach to performance testing, making it a valuable asset in maintaining high-quality software standards.

---

# Demo

This demo is provided by Grafana labs itself. Was named QuickPizza demo app.

* [k6-workshop](https://github.com/aniqaqill/k6-oss-workshop)
    
* [QuickPizza](https://github.com/grafana/quickpizza)
    

Somehow k6-workshop need minor fix to run the test can view [this issues for solution](https://github.com/grafana/k6-oss-workshop/issues/4#issuecomment-2663246289)

---

# More Sources

* [k6 Learn](https://github.com/grafana/k6-learn)
    
* [k6 OSS Workshop](https://github.com/grafana/k6-oss-workshop?tab=readme-ov-file#before-we-start)
    
* [Awesome k6](https://github.com/grafana/awesome-k6)
    
* [Load Testing with k6](https://levelup.gitconnected.com/load-testing-with-k6-48488c7946bb)
    
* [k6 Operator for K8s](https://github.com/grafana/k6-learn/blob/main/Modules/XX-Future-Ideas/How-to-use-the-k6-operator-for-Kubernetes.md)
    
* [Chaos testing with k6 and Friends](https://www.youtube.com/watch?v=2QHs_HEX7r0)
    
* [Basic k6 Load Testing Setup](https://youtu.be/XR2MAivt-9E?si=IlauKGqcsVKGx3rC)
    
* [Chai with k6](https://grafana.com/docs/k6/latest/testing-guides/use-chai-with-k6/)
