# Arfan Uddin - Full Site Content # Generated: 2026-08-20T22:14:20.596Z # URL: https://arfanu.com This document contains the full content of arfanu.com for AI/LLM consumption. For a summary, see: https://arfanu.com/llms.txt --- ## Site Owner Name: Md Arfan Uddin Role: PhD Student in Software Engineering, University of Arizona Focus: AI/LLM applications in Microservices Founder: Connecto (https://getconnecto.app) ## Expertise - Software Engineering Research - Large Language Models (LLMs) - Microservices & Distributed Systems - Full-stack Development (Next.js, Spring Boot, Kafka, Redis) - Mobile Development (Android, Flutter) - DevSecOps --- ## Blog Posts ### The Security Bug Your Tests Cannot See **URL:** https://arfanu.com/blog/microservice-authorization-testing-llm **Date:** 2026-07-27 **Author:** Arfan Uddin **Description:** Apps are built from dozens of services that each decide who is allowed in. We used AI to test the doors nobody checks, and found all 16 planted security flaws. title: "The Security Bug Your Tests Cannot See", description: "Apps are built from dozens of services that each decide who is allowed in. We used AI to test the doors nobody checks, and found all 16 planted security flaws.", date: "2026-07-27", author: "Arfan Uddin", tags: ["microservice-security", "authorization-testing", "authorization-drift", "LLM-test-generation", "broken-access-control", "software-testing", "IEEE-SOSE", "research"], paperUrl: "https://doi.org/10.1109/SOSE71128.2026.00014", pdfAttachment: "https://assets.arfanu.com/research-article/microservice-authorization-testing-llm/paper.pdf", alternates: { canonical: "/blog/microservice-authorization-testing-llm", }, openGraph: { type: 'article', title: "The Security Bug Your Tests Cannot See", description: "Apps are built from dozens of services that each decide who is allowed in. We used AI to test the doors nobody checks, and found all 16 planted security flaws.", url: 'https://arfanu.com/blog/microservice-authorization-testing-llm', siteName: 'Arfan Uddin', images: [{ url: 'https://assets.arfanu.com/research-article/microservice-authorization-testing-llm/og-image.jpg', width: 1200, height: 630, alt: 'Closing the microservice authorization blindspot, research presented at IEEE SOSE 2026 in Fukuoka, Japan', }], publishedTime: '2026-07-27', authors: ['Arfan Uddin'], }, twitter: { card: 'summary_large_image', title: "The Security Bug Your Tests Cannot See", description: "Apps are built from dozens of services that each decide who is allowed in. We used AI to test the doors nobody checks, and found all 16 planted security flaws.", images: ['https://assets.arfanu.com/research-article/microservice-authorization-testing-llm/og-image.jpg'], }, }; const isExternal = href.startsWith('http'); return ( ); }; const styles = { info: "bg-blue-50 dark:bg-blue-950/30 border-blue-200 dark:border-blue-800", warning: "bg-amber-50 dark:bg-amber-950/30 border-amber-200 dark:border-amber-800", insight: "bg-emerald-50 dark:bg-emerald-950/30 border-emerald-200 dark:border-emerald-800", danger: "bg-red-50 dark:bg-red-950/30 border-red-200 dark:border-red-800", }; const icons = { info: --- ## One Click, Many Doors Modern apps are rarely one big program. They are built as **microservices**, which means the app is chopped into dozens of small programs that call each other over a network. Booking a train ticket in one click might quietly involve a login service, an order service, a payment service, and a seat service, each one handing the request along to the next. Every one of those services decides for itself who is allowed to do what. That decision is called **authorization**, and it is made independently in dozens of places, by different teams, on different schedules. So the rules drift apart. One team tightens a rule. Another team rewrites a service and accidentally stops passing along proof of who you are. Nothing appears broken, because the front desk still says yes. , the industry's standard list of the most serious web security risks. Failures of this kind have been linked to major incidents at companies including Google and Uber. --- ## Why Today's Testing Tools Miss It There are good automated tools that generate security tests. The best known are EvoSuite and EvoMaster. They share one habit: they knock on the front door and stop there. Everything behind it is a black box to them. Both halves of that picture show the same app. On the left, the tool can only see the first step, so it raises an alarm it cannot back up. On the right, the tool follows the request through every step and gets the answer right. A tool that only sees the entrance fails in two directions at once. It cries wolf about problems it cannot confirm, and it stays silent about real ones happening out of sight. --- ## The Idea: Work Out the Answer First, Then Let AI Write the Test The obvious move is to point an AI model at the code and ask for security tests. That does not work well. The code is far too big to fit, most of it is irrelevant, and the model has no reliable way to know which service calls which. So we did it the other way around. **Step one is arithmetic, not AI.** We read the source code automatically and build a map of every service, every door, and the permission rule on each one. Then, for any journey through the app, we ask a simple question: > Does this person's badge open *every single door* along the route? If yes, they should get in. If any one door refuses, they should be turned away. There is no judgement involved. It is the same logic as a padlocked chain: one locked link stops the whole thing. **Step two is where AI comes in.** By this point we already know the right answer for every person and every route. The AI is never asked what *should* happen. It is only asked to write the actual test that checks it, which means filling in a realistic request with sensible data. --- ## Drawing the Map To make any of this possible, we first have to figure out which service calls which, automatically, from the source code alone. The tricky part is spotting the moments when one service reaches across the network to call another. Those calls are the doors nobody tests. On our test system, this found **399 of 418** such jumps, about 95%. The 19 it missed were cases where the destination is decided while the program is running, so it cannot be worked out just by reading the code. We deliberately leave those marked as unknown rather than guessing, because a confident wrong answer is worse than an admitted gap. Some of these journeys are surprisingly deep. The longest ran through **17 services** before finishing. --- ## What Happened We tested this on **Train-Ticket**, a realistic 20-service demo train booking system that researchers use as a standard yardstick. Then we deliberately broke it, planting faulty permission rules the way a careless code change would, and checked whether the tests caught them. ### Against other testing tools EvoMaster is a genuinely good tool. It always aims at the right place and writes sensible checks. It simply has no way of knowing what happens after the first step, so fewer than half its tests line up with a real journey through the system. EvoSuite produced four tests in total, none of them meaningful for this kind of app. To be fair in the other direction: EvoMaster's tests ran without technical errors 100% of the time, against 97.4% for ours. On raw stability, it beat us. ### Against the mathematical approach There is a rival school of thought that proves security properties mathematically instead of testing them. We compared against one such tool, using 16 planted flaws. The proof-based tool declared all 16 broken cases secure. Ours caught every one, at the cost of a single false alarm. That sounds like a rout, and in this test it was. But the fair reading is narrower: a mathematical proof describes what the design *should* do. It cannot tell you what the software running on real servers, with real configuration and half-finished changes, is *actually* doing. The two approaches answer different questions, and this result is an argument for using both. ### Being honest about the rough edges Not everything scored 100%. When assigning which roles to test, the system got it right **82%** of the time. Coverage of routes and roles was complete, but that role-matching gap is real and we report it as such. The tests themselves ran cleanly **97.4%** of the time, and the whole process takes about **16 seconds per scenario**, which is fast enough to run automatically every time code changes. --- ## The Bug We Found by Accident Beyond the flaws we planted on purpose, the system turned up a real one we did not know about: a service that forgot to pass along proof of identity when calling the next service down the line. Legitimate, properly logged-in users were being turned away deep inside the app. No tool that stops at the front door could have found that. It also taught us something honest about the limits of this work. Once you start testing deep inside an app, you run into ordinary bugs as much as security ones. Requests often fail not because permission was refused, but because the data they needed was not there. --- ## What This Means If You Build Software 1. **Test the inside doors, not just the entrance.** If your security tests all stop at the API gateway, they are testing the lobby. 2. **Treat "allowed in, blocked later" as a red flag.** It is either a genuine security hole or a feature nobody can actually reach. Both are worth a look. 3. **Check what your public endpoints expose.** Our crude keyword scan for words like `payment` and `profile` still turned up things that should not have been public. 4. **A crash is not a rejection.** If your tests count any error as "correctly blocked", some of them are passing for the wrong reason. And the broader lesson about AI: models are far more reliable when you hand them a fact to verify than when you ask them to supply the fact. Pin down the answer with ordinary analysis first, and use the model for the part it is genuinely good at. --- ## What This Does Not Prove I would rather state the limits plainly than oversell it. **It is one system, and a small slice of it.** The results come from 13 entry points on a single test application. Train-Ticket is a respected benchmark, but there is no standard collection of real permission bugs to test against, so we checked every finding by hand. **It only works on one kind of codebase so far.** The code reader is built for Java Spring, a common but far from universal way of building services. The underlying idea carries over; the tool would need rewriting for each new language. **It cannot see rules enforced outside the code.** Plenty of permission rules live in network infrastructure rather than in the application itself. Those are invisible to this approach. **It does not scale for free.** Checking every role against every route across every path multiplies quickly. On a large system you would need to prioritise rather than test everything. **And there is a trust question.** Companies are understandably wary of letting an AI model gate their releases, and calling a large model on every code change costs real money. The sensible path is probably to shrink this down into a small, specialised model. For anyone who wants the full numbers, the exact statistical breakdowns, and the formal write-up, all of it is in the published paper, available from IEEE at . The prompts, generated tests, and raw results are separately available on under an open licence. If you would like the more technical version of the ideas behind this, my earlier post on covers how we make this scale. --- ## Common Questions ### What is a microservice? One small program that does one job inside a bigger app. Rather than building an app as a single large program, teams split it into dozens of small services that talk to each other over a network. ### What is an authorization blindspot? A part of an app where the permission rules disagree between the entrance and the services deeper inside. Because most tools only check the entrance, that mismatch is never tested and stays hidden. ### What is authorization drift? When the permission rules in running software slowly stop matching what the team intended. Each service gets updated on its own schedule, so one team can change or remove a check without anyone else noticing. ### Can AI be trusted to write security tests? Here it is never asked to decide what secure behaviour is. That is worked out in advance by analysing the code. The AI only writes the test that checks an answer we already have, which is a translation job rather than a judgement call. --- ## Citation If you find this work useful, please cite: ```bibtex @INPROCEEDINGS{11652948, author={Uddin, Md Arfan and Weerasinghe, Shakthi and Wojtak, Connor and Cerny, Tomas and Silva-Junior, Deuslirio and Ribeiro, Mateus Eduardo S. and Dos Santos Neto, Manoel Ver{\'i}ssimo and Graciano-Neto, Valdemar V. and Galv{\~a}o, Arlindo and Abdelfattah, Amr S.}, booktitle={2026 International Conference on Service-Oriented System Engineering (SOSE)}, title={Automated Generation of Microservice Authorization Tests Using Large Language Models}, year={2026}, pages={41-50}, doi={10.1109/SOSE71128.2026.00014}} ``` --- ## About This Research This work was done at the **University of Arizona** with collaborators at the **Federal University of Goiás** in Brazil, supported by the **National Science Foundation** under Grant No. 2409933. All experiments and data processing were carried out by the university collaborators on university-managed resources. Thanks to my advisor and the research group. The prompts, generated tests, and raw results are published openly on . If you work on this kind of problem, or just want to talk about it, . --- ### Master's Complete: MS in Software Engineering at Arizona **URL:** https://arfanu.com/blog/ms-software-engineering-arizona **Date:** 2026-05-15 **Author:** Arfan **Description:** I earned my MS in Software Engineering at the University of Arizona on the way to the PhD. A milestone worth pausing on: what it took, what it taught me, and what comes next. title: "Master's Complete: MS in Software Engineering at Arizona", description: "I earned my MS in Software Engineering at the University of Arizona on the way to the PhD. A milestone worth pausing on: what it took, what it taught me, and what comes next.", date: "2026-05-15", author: "Arfan", tags: ["MS", "Software Engineering", "University of Arizona", "PhD", "milestone", "research"], alternates: { canonical: "/blog/ms-software-engineering-arizona", }, openGraph: { type: 'article', title: "Master's Complete: MS in Software Engineering at Arizona", description: "I earned my MS in Software Engineering at the University of Arizona on the way to the PhD. A milestone worth pausing on: what it took, what it taught me, and what comes next.", url: 'https://arfanu.com/blog/ms-software-engineering-arizona', siteName: 'Arfan Uddin', images: [{ url: 'https://assets.arfanu.com/blogs/ms-software-engineering-arizona/ms-graduation-stage.jpg', width: 1200, height: 630, alt: 'Arfan Uddin, MS in Software Engineering, University of Arizona', }], publishedTime: '2026-05-15', authors: ['Arfan Uddin'], }, twitter: { card: 'summary_large_image', title: "Master's Complete: MS in Software Engineering at Arizona", description: "I earned my MS in Software Engineering at the University of Arizona on the way to the PhD.", images: ['https://assets.arfanu.com/blogs/ms-software-engineering-arizona/ms-graduation-stage.jpg'], }, }; const isExternal = href.startsWith('http'); return ( ); }; "@context": "https://schema.org", "@type": "BlogPosting", "headline": metadata.title, "description": metadata.description, "image": ["https://assets.arfanu.com/blogs/ms-software-engineering-arizona/ms-graduation-stage.jpg"], "url": metadata.alternates.canonical, "datePublished": metadata.date, "dateModified": metadata.date, "author": { "@type": "Person", "name": metadata.author, "url": "https://arfanu.com" }, "publisher": { "@type": "Organization", "name": "Arfan's Blog", "logo": { "@type": "ImageObject", "url": "https://arfanu.com/assets/arfan.svg" } }, "keywords": metadata.tags.join(", "), "articleBody": "I earned my MS in Software Engineering at the University of Arizona, completed as a milestone on the way to my PhD. It marks the research foundation I built over the first stretch of doctoral work, including systematic reviews of microservice log analysis, a taxonomy of microservice dependencies, and graph-based LLM prompting for scalable API testing, along with the people who made it possible.", "mainEntityOfPage": { "@type": "WebPage", "@id": metadata.alternates.canonical }, "isAccessibleForFree": "True", "inLanguage": "en-US", "articleSection": "Blog", "wordCount": "950" }; **. 🎓 I want to be honest about what this milestone is, because the honest version is the better story. I didn't set out to do a standalone master's. I came back to Arizona to do a **PhD in Software Engineering**, and the MS is the degree you earn along the way, the marker that the research foundation is in place and the doctoral work can really begin. So this isn't a finish line. It's a checkpoint. But it's one worth pausing on, because the road to it was anything but straight. , you know this wasn't a tidy path: a **CS bachelor's** here in 2020, a few years building software in industry, a year in an **MBA** at Eller before I changed course, and finally the **PhD program in 2024**. Every detour felt uncertain while I was in it. None of it was wasted. The years writing production code (APIs, the KMap migration, systems serving **50,000+ students worldwide for ICPC**) are exactly what make my research questions feel real instead of academic. I'm not studying microservices from the outside; I'm studying problems I've had to ship around at 2 a.m. ## What the master's actually represents The coursework gets you the credits, but the part I'm proud of is the research foundation underneath the degree: - A first-authored **systematic literature review on AI techniques for microservice log analysis**, accepted in the *Journal of Systems and Software*, where we screened 2,208 papers down to 82 studies to map the field. - A co-authored **multivocal study on microservice dependencies**, also in *JSS*, synthesizing thousands of sources into a taxonomy of 28 dependency types. - And the work I'm most excited about: **graph-based LLM prompting for scalable microservice API testing**, which earned **1st runner-up in the Student Research Competition at IEEE CISOSE 2025**. Three years ago "publish in a top journal" was an abstract ambition. Getting the MS means those weren't flukes; they're the start of a research agenda I get to keep building on. **, a real-time networking app for making the right connections in the room before the moment passes, and ****, an effort to connect Bangladeshi students across the world so no one has to navigate a new country alone. Both came from problems I lived, and both keep me building outside the lab. ## The people who got me here Most of all, to my **wife**: thank you for walking this whole road with me. The path was hard. We did it with a new baby, through missed weekends, late nights, and everything in between, and you carried more of it than anyone will ever see. This degree is as much yours as it is mine, and you deserve every bit of it. To my **advisor, [Tomáš Černý](https://tomas-cerny.github.io/), and lab**, thank you for the hard questions and for treating my industry instincts as an asset rather than something to unlearn. To my **collaborators** on every paper, who made the long review cycles bearable. And to the **faculty and family** who kept showing up through a couple of false starts, thank you. ## What comes next The MS closes one chapter and opens the real one. The PhD is where the questions get harder, and I can't wait. The thread I'm pulling on, **making microservice systems more testable, observable, and maintainable, increasingly with LLMs in the loop**, is one I expect to spend years on. If there's one thing I'd tell anyone on a winding path of their own: the detours aren't the cost of the journey. Sometimes they're what makes the destination worth reaching. On to the next chapter. **Bear Down.** 🐾 --- ### One Nomination **URL:** https://arfanu.com/blog/bsa-one-nomination **Date:** 2026-04-20 **Author:** Arfan **Description:** I took over a 150-member student organization that had received exactly one leadership nomination. Eight months later it had 39. Here is what actually happened in between, and the part nobody puts on a resume. title: "One Nomination", description: "I took over a 150-member student organization that had received exactly one leadership nomination. Eight months later it had 39. Here is what actually happened in between, and the part nobody puts on a resume.", date: "2026-04-20", author: "Arfan", tags: ["leadership", "community", "BSA", "institutional-memory", "university-of-arizona"], alternates: { canonical: "/blog/bsa-one-nomination", }, openGraph: { type: 'article', title: "One Nomination", description: "I took over a 150-member student organization that had received exactly one leadership nomination. Eight months later it had 39. Here is what actually happened in between.", url: 'https://arfanu.com/blog/bsa-one-nomination', siteName: 'Arfan Uddin', images: [{ url: 'https://assets.arfanu.com/blogs/bsa-one-nomination/bsa-president-2026.webp', width: 1200, height: 630, alt: 'Bangladeshi Student Association at the University of Arizona', }], publishedTime: '2026-04-20', authors: ['Arfan Uddin'], }, twitter: { card: 'summary_large_image', title: "One Nomination", description: "I took over a 150-member student organization that had received exactly one leadership nomination. Eight months later it had 39.", images: ['https://assets.arfanu.com/blogs/bsa-one-nomination/bsa-president-2026.webp'], }, }; const isExternal = href.startsWith('http'); return ( ); }; "@context": "https://schema.org", "@type": "BlogPosting", "headline": metadata.title, "description": metadata.description, "image": ["https://assets.arfanu.com/blogs/bsa-one-nomination/bsa-president-2026.webp"], "url": metadata.alternates.canonical, "datePublished": metadata.date, "dateModified": metadata.date, "author": { "@type": "Person", "name": metadata.author, "url": "https://arfanu.com" }, "publisher": { "@type": "Organization", "name": "Arfan's Blog", "logo": { "@type": "ImageObject", "url": "https://arfanu.com/assets/arfan.svg" } }, "keywords": metadata.tags.join(", "), "articleBody": "When I took over the Bangladeshi Student Association at the University of Arizona, the organization had received exactly one nomination for its leadership election out of around 150 members. An organization where one person out of a hundred and fifty is willing to lead does not have a leadership problem—it has a belonging problem. Over eight months, four people ran the 150-member organization by reliably showing up: weekly events, tournaments, re-engaging alumni, and giving undergraduates ownership. By the end, the one nomination had become thirty-nine for thirteen roles. But a spike is not a system, and the real test is whether it survives the people who built it.", "mainEntityOfPage": { "@type": "WebPage", "@id": metadata.alternates.canonical }, "isAccessibleForFree": "True", "inLanguage": "en-US", "articleSection": "Blog", "wordCount": "1100" }; # One Nomination When I took over the Bangladeshi Student Association at the University of Arizona, the organization had received exactly one nomination for its leadership election. The chapter had around 150 members. That one nomination was not mine. Someone else had put their name forward; I came in a different way. The community gathered at a meeting and selected me as interim president, because the alternative was an empty chair. I did not win the role. There was nothing to win. That is the honest version, and it matters, because it changes what the problem actually was. An organization where one person out of a hundred and fifty is willing to lead does not have a leadership problem. It has a belonging problem. People do not volunteer to run something they do not feel part of. The single nomination was not the disease. It was one symptom. A community that has to gather in a room and appoint someone because almost nobody will step forward on their own was the other. Bangladeshi Student Association at the University of Arizona ## Four people and eight months The structure on paper had six leadership positions. We had four people. Those four ran a 150-member organization for eight months, which mostly meant doing the unglamorous things repeatedly and in public. We held events nearly every week. We ran tournaments, because nothing rebuilds a group of people who have drifted apart faster than putting them on opposing teams and letting them argue about the score afterward. We went back to the alumni who had quietly disengaged and gave them a reason to show up again. We made the undergraduates feel like the organization was theirs and not a thing run over their heads by graduate students. None of that is strategy. It is just attendance. You become the thing people can rely on by reliably being there, and there is no shortcut that skips the showing up. The metrics moved because the room stopped being empty, not the other way around. ## What I would tell the next person A few things became clear that I did not expect going in. The first is that you should not compete with last year's committee. Every new leader inherits the instinct to out-do the people before them, and it is a trap. A previous team optimized for their own constraints and their own strengths, and trying to beat them on their terms means you are tuning yourself against someone else's local maximum instead of finding your own. You will lose, and worse, you will spend your energy on the wrong axis. Run your organization on what you are actually good at. The second is counterintuitive and I got it wrong before I got it right. When a community has sub-groups inside it, the temptation is to pull a representative from each one into central leadership, on the theory that this unifies everyone. It does the opposite. You do not unify a community by extracting its parts into a committee. You aggregate the sub-groups by giving them room to exist and connecting them, not by dissolving them into a leadership table where they stop being themselves. Expanding our leadership from six roles to thirteen was about giving more of the community real representation, not about manufacturing seats — but the principle underneath it was that representation works when groups stay intact, not when they get absorbed. The third is the one I still think about, and it is an engineering problem disguised as a community one. ## The org had no version control Everything I learned about running a cultural night, a picnic, the annual events, the funding requests — all of it lived in someone's head. There was no record. Each leadership team rediscovered the same problems from scratch every year, made the same mistakes, and then graduated and took the solutions with them. As a software engineer this was physically uncomfortable to watch. It is an organization with no version control, no commit history, no documentation, restarting from a blank file every twelve months and wondering why it never compounds. So before I left I did two things. I documented the operational knowledge — how things actually get done, where they break, what the funding process really looks like underneath the official description. And I created a dedicated role on the board whose entire job is to keep that documentation alive, because a document nobody owns is a document that rots. This is the part I am least certain about, and I want to be honest that it is unfinished. Writing things down once is not the same as building a system that survives the people who built it. ## The numbers, and the caveat By the end of the eight months, the one nomination had become thirty-nine, for thirteen roles, and the organization had thirteen elected officials where it had recently had four exhausted volunteers. Those are real and I am proud of them. But a spike is not a system. The honest test of any of this is not what the participation looked like the month I left. It is what it looks like two and three years from now, after the people who remember me are also gone. If it snaps back to one nomination, then what I built was a personality, not an institution, and the documentation was the only part that actually mattered. I do not get to know that yet. You do not get to call a turnaround a success until it survives you, and mine has not had the chance to be tested. I wrote a letter to whoever runs this next. Most of it was not about what we achieved. It was about the parts that are still load-bearing and easy to break. That felt like the right thing to leave behind. Not a record of what we did, but an honest map of where the floor is thin. --- ### Why Your Microservices Keep Breaking: A Deep Dive into Dependency Management **URL:** https://arfanu.com/blog/microservice-dependencies-maintainability **Date:** 2026-02-26 **Author:** Arfan Uddin **Description:** Learn how hidden dependencies cause 56% of microservice failures and discover 4 proven strategies to detect architectural degradation before it impacts production. title: "Why Your Microservices Keep Breaking: A Deep Dive into Dependency Management", description: "Learn how hidden dependencies cause 56% of microservice failures and discover 4 proven strategies to detect architectural degradation before it impacts production.", date: "2026-02-26", author: "Arfan Uddin", tags: ["microservices", "software-architecture", "dependencies", "maintainability", "distributed-systems", "devops"], paperUrl: "https://doi.org/10.1007/978-3-032-17286-0_2", pdfAttachment: "https://assets.arfanu.com/research-article/ms-dependency-management-maintainabilty/On%20Dependencies%20in%20Microservices.pdf", ogImage: "https://assets.arfanu.com/research-article/ms-dependency-management-maintainabilty/fig-5.png", alternates: { canonical: "/blog/microservice-dependencies-maintainability", }, openGraph: { type: 'article', title: "Why Your Microservices Keep Breaking: A Deep Dive into Dependency Management", description: "Learn how hidden dependencies cause 56% of microservice failures and discover 4 proven strategies to detect architectural degradation before it impacts production.", url: 'https://arfanu.com/blog/microservice-dependencies-maintainability', siteName: 'Arfan Uddin', images: [{ url: 'https://assets.arfanu.com/research-article/ms-dependency-management-maintainabilty/fig-5.png', width: 1200, height: 630, alt: 'Tree metaphor showing dependencies as roots supporting architecture and maintainability', }], publishedTime: '2026-02-26', authors: ['Arfan Uddin'], }, twitter: { card: 'summary_large_image', title: "Why Your Microservices Keep Breaking: Dependency Management Deep Dive", description: "4 proven strategies to detect architectural degradation before it impacts production", images: ['https://assets.arfanu.com/research-article/ms-dependency-management-maintainabilty/fig-5.png'], }, }; const isExternal = href?.startsWith('http'); return ( ); }; const isExternal = href?.startsWith('http'); if (!href) return ; const variants = { primary: "bg-primary/10 text-primary hover:bg-primary/20 border-primary/30", github: "bg-gray-900 text-white hover:bg-gray-800 border-gray-700", docs: "bg-blue-500/10 text-blue-600 hover:bg-blue-500/20 border-blue-500/30", }; return ( ); }; const styles = { info: "bg-blue-50 dark:bg-blue-950/30 border-blue-200 dark:border-blue-800", warning: "bg-amber-50 dark:bg-amber-950/30 border-amber-200 dark:border-amber-800", insight: "bg-emerald-50 dark:bg-emerald-950/30 border-emerald-200 dark:border-emerald-800", }; const icons = { info: and extended in a Springer volume**—investigates how dependencies impact maintainability and provides concrete strategies for managing them effectively. --- ## The Hidden Problem: Explicit vs. Implicit Dependencies When developers assess the impact of changes, they typically focus on **explicit dependencies**—the visible inter-service calls that are immediately recognizable. But there's a whole category of **implicit dependencies** that escape attention during change assessment. --- ## Four Problem Areas Where Dependencies Strike Our analysis identified four key areas where dependencies manifest and cause issues:
### 2. Smell Detection Strategies Tools like **SonarQube** help identify anti-patterns, but traditional smell detection is optimized for monolithic repositories. In microservices, anti-patterns can extend across various components. **The key insight**: Smells often only signal *symptoms* of deeper problems. Dependencies provide a foundational view of system interrelations without requiring pre-defined rules. Comparing system versions makes the impact of changes more quantifiable than merely relying on anti-pattern catalogs. ### 3. Architecture Reconstruction Strategies Architecture reconstruction maps services and their interactions while delving into underlying dependencies and architectural logic. Recent advances enable automation of extracting and analyzing both static and dynamic aspects of codebases. **Challenge**: Focus on explicit dependencies and control flows often overlooks subtler, implicit connections between components. Enriching reconstructed models with comprehensive dependency mapping enables more robust analysis. ### 4. Architectural Rule Violation Detection Rules dictate that service layers communicate solely through specified interfaces, avoiding unauthorized access patterns. Effectiveness hinges on comprehensive cataloging of all dependencies—missed dependencies diminish rule effectiveness. --- ## A Practical Example: Fraud Detection System Consider a fraud detection system monitoring transactions for fraudulent activities: ### Data Dependencies & Solutions Data dependencies arise when microservices share or access the same data entities. Changes in data schemas must be coordinated across services. **Mitigation patterns:** - **Tolerant Reader**: Design services to handle unknown or extra data gracefully - **Request Mapper**: Transform incoming requests to decouple internal logic from external data formats ### Control Dependencies & Solutions Control dependencies arise when one service's execution depends on the control flow or state of another. **Tools:** - **TraceNet**: Analyzes tracing data to pinpoint root causes of problems - **GDC-DVF**: Maps invocation relationships and extracts dependencies for monolith-to-microservice transitions ### Communication Dependencies & Solutions Communication dependencies involve service interactions through synchronous or asynchronous mechanisms. **Tools:** - **ChainsFormer**: Analyzes communication patterns to identify critical paths for resource provisioning - **GSMART**: Creates service dependency graphs (SDGs) for tracing relationships and regression testing ### Resource Dependencies & Solutions Resource dependencies cause contention and performance degradation when services share computational resources. **Tools:** - **DeepScaler**: Uses affinity matrices to scale microservices dynamically based on usage patterns - **SYMBIOTE**: Monitors coupling metrics to detect architectural degradation and optimize allocation --- ## Maintainability: The Five Quality Attributes Dependencies directly impact the five ISO 25010 maintainability attributes: with questions or to discuss the research! --- ### AI for Microservice Log Analysis: Key Insights from 82 Research Studies **URL:** https://arfanu.com/blog/ai-microservice-log-analysis-slr **Date:** 2026-01-20 **Author:** Arfan Uddin **Description:** A comprehensive analysis of AI techniques for microservice log analysis, covering anomaly detection, root cause analysis, and the research-practice gap affecting enterprise adoption. title: "AI for Microservice Log Analysis: Key Insights from 82 Research Studies", description: "A comprehensive analysis of AI techniques for microservice log analysis, covering anomaly detection, root cause analysis, and the research-practice gap affecting enterprise adoption.", date: "2026-01-20", author: "Arfan Uddin", tags: ["AI", "microservices", "log-analysis", "anomaly-detection", "machine-learning", "DevOps", "research"], paperUrl: "https://doi.org/10.1016/j.jss.2026.112786", pdfAttachment: "https://assets.arfanu.com/research-article/ai-microservice-log-analysis-slr/paper.pdf", alternates: { canonical: "/blog/ai-microservice-log-analysis-slr", }, openGraph: { type: 'article', title: "AI for Microservice Log Analysis: Key Insights from 82 Research Studies", description: "A comprehensive analysis of AI techniques for microservice log analysis, covering anomaly detection, root cause analysis, and the research-practice gap affecting enterprise adoption.", url: 'https://arfanu.com/blog/ai-microservice-log-analysis-slr', siteName: 'Arfan Uddin', images: [{ url: 'https://assets.arfanu.com/research-article/ai-microservice-log-analysis-slr/og-image.png', width: 1200, height: 630, alt: 'AI for Microservice Log Analysis - Taxonomy of AI techniques', }], publishedTime: '2026-01-20', authors: ['Arfan Uddin'], }, twitter: { card: 'summary_large_image', title: "AI for Microservice Log Analysis: Key Insights from 82 Research Studies", description: "A comprehensive analysis of AI techniques for microservice log analysis, covering anomaly detection, root cause analysis, and the research-practice gap affecting enterprise adoption.", images: ['https://assets.arfanu.com/research-article/ai-microservice-log-analysis-slr/og-image.png'], }, }; const isExternal = href.startsWith('http'); return ( ); }; const isExternal = href?.startsWith('http'); if (!href) return ; const variants = { primary: "bg-primary/10 text-primary hover:bg-primary/20 border-primary/30", github: "bg-gray-900 text-white hover:bg-gray-800 border-gray-700", docs: "bg-blue-500/10 text-blue-600 hover:bg-blue-500/20 border-blue-500/30", }; return ( ); }; const styles = { info: "bg-blue-50 dark:bg-blue-950/30 border-blue-200 dark:border-blue-800", warning: "bg-amber-50 dark:bg-amber-950/30 border-amber-200 dark:border-amber-800", insight: "bg-emerald-50 dark:bg-emerald-950/30 border-emerald-200 dark:border-emerald-800", }; const icons = { info: **—analyzed **82 primary studies** from 2,208 papers published between 2018 and 2025, examining how AI is being applied to microservice log analysis. The findings reveal both exciting progress and significant gaps between academic research and enterprise needs. --- ## The Big Picture Before diving into details, here's the landscape of AI-powered log analysis research at a glance: ### Why Different Techniques Excel --- ## The Anomaly Detection Bias Not all log analysis tasks receive equal attention. Here's where researchers focus their efforts: --- ## The Dataset Problem Perhaps the most significant finding is the disconnect between research environments and real-world conditions. **79.3% of studies** use synthetic or private datasets—raising serious questions about generalizability. Models trained on clean, well-structured synthetic data may struggle with the noise, inconsistency, and scale of production logs. Only **20.7%** of studies use public benchmarks. ### Public Datasets Available Today For researchers looking to improve reproducibility: --- ## Tools You Can Use Today Our review identified numerous open-source implementations. Here are the most notable tools across different categories: ### For Anomaly Detection (Sequence-Based) - **** — LSTM-based approach that learns sequential log patterns. The foundational work that many later tools build upon. - **** — Combines attention-based GRU with hierarchical classification. Great for scenarios with limited labeled data. ### For Anomaly Detection (Transformer/LLM-Based) - **** — Template-free log analysis using pre-trained BERT. Eliminates the need for manual log parsing. - **** — Uses GPT-4 for in-context reasoning to explain and classify anomalies. Shows promise for one-shot root cause analysis. ### For Dependency-Aware Analysis (GNN-Based) - **** — Models spatial-temporal trace event graphs for systems with complex service dependencies. - **** — Unifies invocation path and response time analysis using deep Bayesian networks. ### Supporting Infrastructure - **** — Pre-trained models for building custom log analysis solutions - **** — GNN implementations for graph-based analysis - **** — Collection of system log datasets for benchmarking --- ## Performance: The Good and The Concerning ### What's Working When AI techniques work, they work impressively well: ### What's Challenging However, deployment challenges remain significant: - **56% of studies** report data limitations (label scarcity, quality issues, log heterogeneity) - **51% of studies** face reliability concerns (false positives, concept drift, model degradation) - **50% of studies** encounter resource constraints (GPU requirements, training time, inference latency) --- ## Recommendations ### If You're a Researcher 1. **Prioritize realistic datasets** — 79.3% of studies use synthetic data. Work with enterprise partners to access production logs. 2. **Address efficiency alongside accuracy** — 50% of studies report resource constraints. Production systems need lightweight solutions. 3. **Explore the gaps** — Fault diagnosis (6%) and dependency modeling (4%) are underserved but critical for practitioners. 4. **Design for drift** — Production logs evolve continuously. Online learning approaches are needed. ### If You're a Practitioner 1. **Start with anomaly detection** — It's the most mature area with many open-source tools available. 2. **Evaluate resource requirements first** — LLMs require significant GPU resources. Consider your infrastructure constraints. 3. **Consider hybrid approaches** — 53.9% of studies use hybrid methods for good reason—they combine multiple strengths. 4. **Invest in log standardization** — reduces the "instrumentation tax" and makes AI adoption easier. --- ## Looking Ahead Several trends point toward the next generation of log analysis AI: **LLM Integration** — Large language models show promise for semantic log understanding, but computational costs need optimization. Tools like demonstrate potential for one-shot root cause analysis. **Hybrid Architectures** — Combining GNNs (for dependency modeling) with transformers (for sequence understanding) addresses both structural and semantic understanding needs. **Enterprise-Realistic Benchmarks** — The community needs new datasets that capture production complexity—including noise, schema drift, and multi-tenant scenarios. **Federated Learning** — Privacy-preserving techniques like could enable cross-organization learning without exposing sensitive log data. --- ## Methodology Our systematic review followed PRISMA guidelines, searching across Scopus, IEEE Xplore, ACM Digital Library, and SpringerLink. **. The full paper includes detailed methodology, complete technique taxonomies, and extended analysis of each primary study. The is available on Zenodo. --- ## Appendix: Complete Tool Reference For practitioners looking for a comprehensive reference, here's the full catalog of tools and techniques identified in our review. ### Sequence-Based Tools (LSTM/RNN) ### Transformer and LLM-Based Tools ### Graph Neural Network Tools ### Active Learning and Human-in-the-Loop Tools ### Supporting Frameworks and Libraries --- ### Winning 1st Runner Up at IEEE CISOSE: Graph-Based LLM Prompting for Microservice API Testing **URL:** https://arfanu.com/blog/graph-based-llm-microservice-testing **Date:** 2025-07-23 **Author:** Arfan Uddin **Description:** How I used Interprocedural Control Flow Graphs to make LLM-based API test generation scalable for microservices - 1st runner up IEEE CISOSE 2025 SRC. title: "Winning 1st Runner Up at IEEE CISOSE: Graph-Based LLM Prompting for Microservice API Testing", description: "How I used Interprocedural Control Flow Graphs to make LLM-based API test generation scalable for microservices - 1st runner up IEEE CISOSE 2025 SRC.", date: "2025-07-23", author: "Arfan Uddin", tags: ["research", "IEEE", "microservices", "API-testing", "LLM", "software-engineering", "award"], paperUrl: "https://doi.org/10.1109/SOSE67019.2025.00034", pdfAttachment: "https://assets.arfanu.com/research-article/graph-based-llm-microservice-testing/paper.pdf", alternates: { canonical: "/blog/graph-based-llm-microservice-testing", }, openGraph: { type: 'article', title: "Winning 1st Runner Up at IEEE CISOSE: Graph-Based LLM Prompting for Microservice API Testing", description: "How I used Interprocedural Control Flow Graphs to make LLM-based API test generation scalable for microservices - 1st runner up IEEE CISOSE 2025 SRC.", url: 'https://arfanu.com/blog/graph-based-llm-microservice-testing', siteName: 'Arfan Uddin', images: [{ url: 'https://assets.arfanu.com/research-article/graph-based-llm-microservice-testing/og-image.png', width: 1200, height: 630, alt: 'ICFG-based LLM prompting architecture for microservice API testing', }], publishedTime: '2025-07-23', authors: ['Arfan Uddin'], }, twitter: { card: 'summary_large_image', title: "Winning 1st Runner Up at IEEE CISOSE: Graph-Based LLM Prompting for Microservice API Testing", description: "How I used Interprocedural Control Flow Graphs to make LLM-based API test generation scalable for microservices - 1st runner up IEEE CISOSE 2025 SRC.", images: ['https://assets.arfanu.com/research-article/graph-based-llm-microservice-testing/og-image.png'], }, }; const isExternal = href.startsWith('http'); return ( ); }; const isExternal = href?.startsWith('http'); if (!href) return ; const variants = { primary: "bg-primary/10 text-primary hover:bg-primary/20 border-primary/30", github: "bg-gray-900 text-white hover:bg-gray-800 border-gray-700", docs: "bg-blue-500/10 text-blue-600 hover:bg-blue-500/20 border-blue-500/30", }; return ( ); }; const styles = { info: "bg-blue-50 dark:bg-blue-950/30 border-blue-200 dark:border-blue-800", warning: "bg-amber-50 dark:bg-amber-950/30 border-amber-200 dark:border-amber-800", insight: "bg-emerald-50 dark:bg-emerald-950/30 border-emerald-200 dark:border-emerald-800", award: "bg-yellow-50 dark:bg-yellow-950/30 border-yellow-200 dark:border-yellow-800", }; const icons = { info:
--- ## Research Overview --- ## The Problem: Why Current LLM-Based Testing Struggles Large Language Models have demonstrated impressive code understanding capabilities. Naturally, researchers have explored using them for automated test generation. The idea is simple: feed the LLM your source code, and let it generate comprehensive test cases. But for microservices, this approach breaks down: --- ## The Solution: ICFG-Based Prompting Instead of feeding entire source code to the LLM, this approach uses **Interprocedural Control Flow Graphs (ICFGs)** to extract precisely the code paths relevant to each API endpoint. ### What is an ICFG? An ICFG represents program execution flow across function boundaries. Unlike a simple call graph that just shows which functions call which, an ICFG captures: - **Control flow within functions** (branches, loops, conditions) - **Data dependencies** between functions - **Complete execution paths** from entry point to exit For API testing, this means we can trace exactly what code gets executed for any given endpoint request—and nothing more. --- ## How It Works
--- ## Future Directions This work opens several research directions: **Async Behavior Handling** — Current ICFG construction focuses on synchronous execution paths. Microservices heavily use async patterns (message queues, event-driven architectures) that require extended graph models. **Cross-Service Integration Testing** — The current approach tests individual microservices. Extending ICFGs across service boundaries could enable integration test generation that covers end-to-end workflows. **API Contract Enrichment** — Combining ICFG-derived paths with OpenAPI specifications could provide even richer context for test generation, including request/response schema validation. --- ## Award Recognition I'm grateful to my advisor and the research group at the University of Arizona for their guidance and support throughout this project. --- ## Citation If you find this work useful, please cite: ```bibtex @inproceedings{uddin2025graph, title={Graph-Based LLM Prompting for Scalable Microservice API Testing}, author={Uddin, Md Arfan}, booktitle={2025 IEEE International Conference on Service-Oriented System Engineering (SOSE)}, year={2025}, organization={IEEE}, doi={10.1109/SOSE67019.2025.00034} } ``` --- ## About This Research This research was conducted at the **University of Arizona** as part of my graduate studies in software engineering. The work focuses on improving developer productivity through intelligent tooling that leverages modern AI capabilities. The code is available on . Feel free to if you have questions or want to collaborate on related research. --- ### Hello, I'm Arfan 👋 **URL:** https://arfanu.com/blog/about-me **Date:** 2025-05-05 **Author:** Arfan **Description:** A quick introduction to my work, interests, and what you'll find on this site. title: "Hello, I'm Arfan 👋", description: "A quick introduction to my work, interests, and what you'll find on this site.", date: "2025-05-05", author: "Arfan", tags: ["introduction", "software-engineering", "phd", "startup", "community"], alternates: { canonical: "/blog/about-me", }, openGraph: { type: 'article', title: "Hello, I'm Arfan 👋", description: "A quick introduction to my work, interests, and what you'll find on this site.", url: 'https://arfanu.com/blog/about-me', siteName: 'Arfan Uddin', images: [{ url: 'https://arfanu.com/og-default.png', width: 1200, height: 630, alt: 'Arfan Uddin - Software Engineer & Researcher', }], publishedTime: '2025-05-05', authors: ['Arfan Uddin'], }, twitter: { card: 'summary_large_image', title: "Hello, I'm Arfan 👋", description: "A quick introduction to my work, interests, and what you'll find on this site.", images: ['https://arfanu.com/og-default.png'], }, }; "@context": "https://schema.org", "@type": ["Person", "ProfilePage"], "name": "Md Arfan Uddin", "givenName": "Arfan", "familyName": "Uddin", "url": metadata.alternates.canonical, "image": { "@type": "ImageObject", "url": "/images/arfan.png", "contentUrl": "/images/arfan.png", "caption": "Md Arfan Uddin" }, "description": metadata.description, "sameAs": [ "https://www.linkedin.com/in/rfn/", "https://github.com/arfan-rfn", "https://getconnecto.app", "https://bdstudents.org" ], "affiliation": { "@type": "Organization", "name": "University of Arizona", "url": "https://www.arizona.edu" }, "alumniOf": { "@type": "Organization", "name": "University of Arizona" }, "jobTitle": "Ph.D. Student in Software Engineering", "worksFor": [ { "@type": "Organization", "name": "Connecto", "url": "https://getconnecto.app", "foundingDate": "2025", "founder": { "@type": "Person", "name": "Md Arfan Uddin" } }, { "@type": "Organization", "name": "BDStudents", "url": "https://bdstudents.org", "founder": { "@type": "Person", "name": "Md Arfan Uddin" } } ], "knowsAbout": [ "Software Engineering", "Artificial Intelligence", "Large Language Models", "Microservices", "Root Cause Analysis", "Full-stack Development", "Mobile Development" ], "mainEntityOfPage": { "@type": "WebPage", "@id": metadata.alternates.canonical, "datePublished": metadata.date, "dateModified": "2026-06-08", "author": { "@type": "Person", "name": metadata.author }, "publisher": { "@type": "Person", "name": metadata.author }, "headline": metadata.title, "keywords": metadata.tags.join(", "), "inLanguage": "en-US", "isPartOf": { "@type": "WebSite", "name": "Arfan's Blog", "url": "https://arfan.dev" } }, "award": [ "Graduate Assistantship in Software Engineering", "Startup Milestone Funding from Startup Wildcats", "1st Runner-Up, IEEE CISOSE Student Research Competition 2025" ], "hasOccupation": { "@type": "Occupation", "name": "Software Engineer and Researcher", "skills": [ "Next.js", "Spring Boot", "Kafka", "Redis", "Supabase", "DevSecOps", "Microservice Architecture" ] } }; # 👋 Meet Arfan Hey there! I'm **Md Arfan Uddin**, and I'm excited you've found your way here. I'm currently a **Ph.D. student in Software Engineering** at the University of Arizona. My research lies at the intersection of **AI and microservices**, focusing on using **Large Language Models (LLMs)** to improve **Root Cause Analysis (RCA)** in distributed systems. Imagine systems that can automatically analyze logs and traces to tell you what went wrong and how to fix it—this is the future I'm building toward. This isn't just theory for me. My work has been **published in the _Journal of Systems and Software_ and presented at IEEE conferences** (SOSE, CLOSER), and I was honored as **1st runner-up at the IEEE CISOSE Student Research Competition 2025**. If you're curious, I unpack several of these papers in plain language [elsewhere on this blog](/blog). But my journey didn't start in research labs. ### From Code to Cloud to Research With over **4 years of professional experience** as a full-stack and mobile developer, I've worked across multiple domains—from research platforms to real-time apps. I led engineering for **KMap**, a campus-wide research visualization tool, where migrating the platform to **Next.js drove a 6x jump in click-through rate**. Today I build full-stack systems for the **International Collegiate Programming Contest (ICPC)**, supporting **50,000+ participants worldwide**, and earlier I co-created **ScholarPaw**, a scholarship management platform. I've always been passionate about building systems that don't just work—but scale, evolve, and empower. Along the way, I've adopted tools like **Next.js**, **Spring Boot**, **Kafka**, **Redis**, and **Supabase**, and embraced principles of DevSecOps, microservice architecture, and automation. These experiences have deeply shaped how I approach both system design and research. ### Building Connecto: From Frustration to Founding In 2024, I founded [**Connecto**](https://getconnecto.app)—a real-time networking app built to solve a common but overlooked problem: people attending the same event often miss opportunities to meet others around them. Connecto helps users **find and connect with people nearby at events, meetups, or even coffee shops**—all in real time. Whether you're looking to expand your network, meet fellow attendees, or simply find someone with shared interests, Connecto makes that happen effortlessly. It's a startup born out of personal frustration, refined by user feedback, and built for human connection in physical spaces. The traction has been encouraging: Connecto was selected as the **official check-in and identity platform for Hack Arizona 2026**, was used at **IEEE CISOSE 2025**, and earned **Startup Wildcats milestone funding**. ### BDStudents: Connecting Bangladeshi Students Worldwide I'm also the **founder and president** of [**BDStudents**](https://bdstudents.org)—a global community platform on a mission to connect the **Bangladeshi student diaspora**. Studying far from home can be isolating, and finding your people on an unfamiliar campus is harder than it should be. BDStudents bridges that gap. It has already reached **106 institutions across 71 cities and 17 countries**, giving students a place to **find their campus chapter, discover student clubs, share through a social feed, and learn from one another**. Under the hood, it's a multi-tenant platform with role-based access for university chapters and clubs, and a two-layer organization model—ambassadors, club leaders, and moderators—so the community can govern itself at scale. It grew out of my own experience as an international student, and a belief that no one should have to navigate that journey alone. That same instinct shows up offline, too: I served as **interim president of the Bangladeshi Student Association at the University of Arizona**, where a small team helped rebuild a demoralized 150-member chapter and grow election participation from a single nomination to 39. ### Why This Blog Exists This blog is a journal of my journey—part research log, part builder's notebook, and part personal reflection. You'll find posts on: - 🚀 AI and LLM applications in software engineering - 🧠 Research insights on debugging microservices - 🛠 Building scalable systems and side projects - 💼 Lessons from transitioning into tech entrepreneurship - 🧑‍🏫 Life as a PhD + MBA student juggling research, coding, and startups ### Let's Connect If you're a fellow researcher, engineer, builder, or just someone curious—I'd love to connect. You can find me on [LinkedIn](https://www.linkedin.com/in/rfn/), check out my [GitHub](https://github.com/arfan-rfn), explore [Connecto](https://getconnecto.app), or join the community at [BDStudents](https://bdstudents.org). Thanks for stopping by. Here's to learning, building, and making meaningful things together. 💫 --- ### From Pitch to Funding: How Connecto Won $500 at Startup Night **URL:** https://arfanu.com/blog/startup-wildcats-connecto-funding **Date:** 2025-04-15 **Author:** Arfan **Description:** The story of pitching Connecto at Startup Wildcats' Startup Night and winning $500 in milestone funding—from nervous preparation to the moment of validation. title: "From Pitch to Funding: How Connecto Won $500 at Startup Night", description: "The story of pitching Connecto at Startup Wildcats' Startup Night and winning $500 in milestone funding—from nervous preparation to the moment of validation.", date: "2025-04-15", author: "Arfan", tags: ["startup", "connecto", "entrepreneurship", "funding", "startup-wildcats", "university-of-arizona", "pitch"], alternates: { canonical: "/blog/startup-wildcats-connecto-funding", }, openGraph: { type: 'article', title: "From Pitch to Funding: How Connecto Won $500 at Startup Night", description: "The story of pitching Connecto at Startup Wildcats' Startup Night and winning $500 in milestone funding.", url: 'https://arfanu.com/blog/startup-wildcats-connecto-funding', siteName: 'Arfan Uddin', images: [{ url: 'https://assets.arfanu.com/blogs/startup-wildcats/og-image.jpeg', width: 1200, height: 630, alt: 'Arfan pitching Connecto at Startup Night', }], publishedTime: '2025-04-15', authors: ['Arfan Uddin'], }, twitter: { card: 'summary_large_image', title: "From Pitch to Funding: How Connecto Won $500 at Startup Night", description: "The story of pitching Connecto at Startup Wildcats' Startup Night and winning $500 in milestone funding.", images: ['https://assets.arfanu.com/blogs/startup-wildcats/og-image.jpeg'], }, }; const isExternal = href.startsWith('http'); return ( ); }; "@context": "https://schema.org", "@type": "BlogPosting", "headline": metadata.title, "description": metadata.description, "image": ["https://assets.arfanu.com/blogs/startup-wildcats/og-image.jpeg"], "url": metadata.alternates.canonical, "datePublished": metadata.date, "dateModified": metadata.date, "author": { "@type": "Person", "name": metadata.author, "url": "https://arfanu.com" }, "publisher": { "@type": "Organization", "name": "Arfan's Blog", "logo": { "@type": "ImageObject", "url": "https://arfanu.com/assets/arfan.svg" } }, "keywords": metadata.tags.join(", "), "articleBody": "The story of pitching Connecto at Startup Wildcats' Startup Night and winning $500 in milestone funding. From the nervousness of stepping on stage to the validation of receiving funding for an idea I believe in.", "mainEntityOfPage": { "@type": "WebPage", "@id": metadata.alternates.canonical }, "isAccessibleForFree": "True", "inLanguage": "en-US", "articleSection": "Blog", "wordCount": "1200" }; . I stood near the stage, rehearsing my pitch one last time in my head, palms slightly sweaty, heart beating just a bit faster than usual. This was the moment I'd been working toward. **, part of , provided exactly the environment I needed. Through their program, I connected with mentors who challenged my assumptions, received feedback that sharpened my pitch, and joined a community of student founders who understood the hustle. The milestone funding program was particularly motivating. It wasn't just about the money—$500 is meaningful, but what it represents matters more. Milestone funding is validation. It says: *we see what you're building, and we believe it's worth supporting.* In the weeks leading up to Startup Night, I practiced my pitch obsessively. In front of mirrors, to friends who would give honest feedback, during late nights when I should have been sleeping. I focused on three things: 1. **The problem**—make it relatable and real 2. **The solution**—keep it clear and compelling 3. **The traction**—show that this isn't just an idea, it's actually being built ## The Pitch Night Experience April 15, 2025. I arrived early, checking in at the venue and greeting familiar faces from the Startup Wildcats community. The energy was electric—a mix of nervous excitement and genuine support. We were all there cheering each other on, even as we competed for the same funding. When my name was called, I walked to the stage, took the microphone, and looked out at the audience. Time seemed to slow down for just a moment. Then I began. I talked about the problem—how we've all felt lost at networking events, how much potential goes unrealized when people don't connect. I demonstrated Connecto's GPS-based check-in, showed how attendees can discover who's nearby, explained the multiple profile modes that let users control exactly how they present themselves. I emphasized privacy—no background tracking, user controls their visibility, professional networking that respects boundaries. And then I shared the traction: Connecto was already live. Not just a prototype, but a real app being used at **IEEE CISOSE 2025**. The audience leaned in. I could feel the energy shifting from polite attention to genuine interest. ## The Moment of Truth After all the pitches were delivered, the judges deliberated. The wait felt eternal. Then the announcements began. Names were called—Natalie R., Cole Withers, Manglam Srivastav, Becca Sanders—all incredible student founders with amazing projects. Over **$5,000** was being distributed across five of us. And then: "**Connecto—Arfan Uddin.**" I walked up to receive the check, feeling a wave of validation wash over me. This wasn't just $500. This was a signal that what I was building mattered to people beyond just me. **. ## For Other Student Founders If you're a student with an idea—whether it's a fully functioning app or just a spark of an insight—I can't recommend **** enough. The mentorship, the community, the opportunity to pitch and receive funding—it all adds up to something genuinely valuable. You don't need to have everything figured out. You just need to start. **Thank you** to Startup Wildcats, Tech Launch Arizona, and everyone who believed in Connecto. This milestone is just the beginning. --- ### HackAZ 2025: Reigniting a Legacy **URL:** https://arfanu.com/blog/hackaz-2025 **Date:** 2025-03-22 **Author:** Arfan **Description:** My experience bringing back HackAZ, one of the Southwest's most iconic hackathons. title: "HackAZ 2025: Reigniting a Legacy", description: "My experience bringing back HackAZ, one of the Southwest's most iconic hackathons.", date: "2025-03-22", author: "Arfan", tags: ["HackAZ", "hackathon", "community", "student-life", "leadership"], alternates: { canonical: "/blog/hackaz-2025", }, openGraph: { type: 'article', title: "HackAZ 2025: Reigniting a Legacy", description: "My experience bringing back HackAZ, one of the Southwest's most iconic hackathons.", url: 'https://arfanu.com/blog/hackaz-2025', siteName: 'Arfan Uddin', images: [{ url: 'https://assets.arfanu.com/blogs/hackaz-2025/og-image.jpeg', width: 1200, height: 630, alt: 'HackAZ 2025 Team', }], publishedTime: '2025-03-22', authors: ['Arfan Uddin'], }, twitter: { card: 'summary_large_image', title: "HackAZ 2025: Reigniting a Legacy", description: "My experience bringing back HackAZ, one of the Southwest's most iconic hackathons.", images: ['https://assets.arfanu.com/blogs/hackaz-2025/og-image.jpeg'], }, }; const isExternal = href.startsWith('http'); return ( ); }; "@context": "https://schema.org", "@type": "BlogPosting", "headline": metadata.title, "description": metadata.description, "image": ["https://assets.arfanu.com/blogs/hackaz-2025/hackaz-2025-img.jpeg"], "url": metadata.alternates.canonical, "datePublished": metadata.date, "dateModified": metadata.date, "author": { "@type": "Person", "name": metadata.author, "url": "https://arfanu.com" }, "publisher": { "@type": "Organization", "name": "Arfan's Blog", "logo": { "@type": "ImageObject", "url": "https://arfanu.com/assets/arfan.svg" } }, "keywords": metadata.tags.join(", "), "articleBody": "After several quiet years, HackAZ finally came back in 2025. My journey with HackAZ started back in 2017 as a volunteer, then as a core organizer in 2018, and now as an Advisor and Organizer. HackAZ 2025 brought together nearly 250 participants for a weekend of non-stop hacking, learning, and connection.", "mainEntityOfPage": { "@type": "WebPage", "@id": metadata.alternates.canonical }, "isAccessibleForFree": "True", "inLanguage": "en-US", "articleSection": "Blog", "wordCount": "1000" }; ** finally came back in 2025—and I feel incredibly grateful to have been part of it as an **Advisor** and **Organizer**. My journey with HackAZ started back in **2017**, when I first joined as a **volunteer**, helping with logistics and supporting participants throughout the event. That experience introduced me to the incredible community of builders, learners, and leaders that HackAZ brings together. In **2018**, I stepped up as a **core organizer**, where I focused on sponsorship outreach and helped bring in the funding that made the event possible. I learned how much effort and collaboration goes into running a large-scale student hackathon—and how rewarding it can be. Then in **2019**, I had the opportunity to **lead two technical workshops**: one on Android app development with Java, and another introducing students to Dart and Flutter. Teaching those sessions was one of the most fulfilling parts of my HackAZ journey—watching students dive in, ask questions, and walk away with something they built themselves. Those moments deepened my connection to the event and reaffirmed my passion for helping others grow through technology. So when the pandemic brought HackAZ to a halt, it felt deeply personal. I had seen firsthand what HackAZ meant to so many students—including myself—and it was hard to watch it go silent for so long. But this year, **WE MADE IT HAPPEN**. HackAZ 2025 took place from March 22 to March 24, a full weekend of non-stop hacking, learning, and connection. With a passionate and dedicated team, we brought HackAZ back to the University of Arizona—and the energy was unreal. We had **nearly 250 participants**, and seeing the event space buzzing with creativity and collaboration again was honestly emotional. Students stayed up through the night, pushing boundaries, turning wild ideas into real prototypes, and supporting each other like they'd known one another for years. As an advisor, I got to work alongside some of the most hardworking and talented student organizers I've met. I was there to guide, mentor, and cheer them on—but truthfully, I learned a lot from them too. Their determination to revive this tradition and make it inclusive, impactful, and fun reminded me of why events like these matter so much. HackAZ 2025 Team
### Looking Ahead HackAZ 2025 wasn't just a restart. It was a **statement**. That even after setbacks and uncertainty, our community is still here—still building, still dreaming, still showing up. To everyone who participated, organized, mentored, or sponsored—**thank you**. And a **special thanks to Kian**, whose leadership and initiative made this revival possible. Your vision brought us all together. HackAZ is back, and I can't wait to see where we take it from here. --- ### Understanding Microservice Dependencies: A Complete Taxonomy from 2,659 Sources **URL:** https://arfanu.com/blog/microservice-dependencies-taxonomy **Date:** 2025-01-21 **Author:** Arfan Uddin **Description:** A comprehensive taxonomy of microservice dependencies synthesized from academic and industry sources, covering 28 dependency types across 6 categories and their impact on system quality. title: "Understanding Microservice Dependencies: A Complete Taxonomy from 2,659 Sources", description: "A comprehensive taxonomy of microservice dependencies synthesized from academic and industry sources, covering 28 dependency types across 6 categories and their impact on system quality.", date: "2025-01-21", author: "Arfan Uddin", tags: ["microservices", "software-architecture", "dependencies", "distributed-systems", "maintainability", "research"], paperUrl: "https://doi.org/10.1016/j.jss.2025.112334", ogImage: "https://assets.arfanu.com/research-article/microservice-dependencies-taxonomy/og-image.png", alternates: { canonical: "/blog/microservice-dependencies-taxonomy", }, openGraph: { type: 'article', title: "Understanding Microservice Dependencies: A Complete Taxonomy from 2,659 Sources", description: "A comprehensive taxonomy of microservice dependencies synthesized from academic and industry sources, covering 28 dependency types across 6 categories and their impact on system quality.", url: 'https://arfanu.com/blog/microservice-dependencies-taxonomy', siteName: 'Arfan Uddin', images: [{ url: 'https://assets.arfanu.com/research-article/microservice-dependencies-taxonomy/og-image.png', width: 1200, height: 630, alt: 'Microservice Dependencies Taxonomy', }], publishedTime: '2025-01-21', authors: ['Arfan Uddin'], }, twitter: { card: 'summary_large_image', title: "Understanding Microservice Dependencies: A Complete Taxonomy", description: "28 dependency types across 6 categories - the complete taxonomy from 2,659 sources", images: ['https://assets.arfanu.com/research-article/microservice-dependencies-taxonomy/og-image.png'], }, }; const isExternal = href.startsWith('http'); return ( ); }; const isExternal = href?.startsWith('http'); if (!href) return ; const variants = { primary: "bg-primary/10 text-primary hover:bg-primary/20 border-primary/30", github: "bg-gray-900 text-white hover:bg-gray-800 border-gray-700", docs: "bg-blue-500/10 text-blue-600 hover:bg-blue-500/20 border-blue-500/30", }; return ( ); }; const styles = { info: "bg-blue-50 dark:bg-blue-950/30 border-blue-200 dark:border-blue-800", warning: "bg-amber-50 dark:bg-amber-950/30 border-amber-200 dark:border-amber-800", insight: "bg-emerald-50 dark:bg-emerald-950/30 border-emerald-200 dark:border-emerald-800", }; const icons = { info: **—synthesized **2,659 sources** (1,733 academic papers + 926 grey literature articles) to create the first comprehensive taxonomy of microservice dependencies. We identified **28 distinct dependency types** across **6 categories**, plus **11 symptom patterns** that indicate underlying dependency issues. --- ## The Big Picture Before diving into details, here's how the 90 synthesized studies map across dependency types, tools, and quality impacts: --- ## Understanding Each Dependency Category ### D1. Data Dependency Data dependencies arise when microservices share or interact with common data entities. **Data Schema Dependency** occurs when multiple services interact with overlapping database schemas or data transfer objects (DTOs). Changes to schema design can cascade across all dependent services. **Parametric Dependency** describes how input parameters influence service behavior and inter-service communication. Configuration changes can silently break downstream services. ### D2. Control Dependency Control dependencies govern how services interact and coordinate their execution. ### D3. Resource Dependency Resource dependencies (also called Technology Dependencies) occur when services share infrastructure or code resources. - **Source Code Dependency**: Shared libraries between services - **Database Dependency**: Multiple services accessing the same database instance - **Environment Dependency**: Configuration settings, credentials, environment variables - **Cluster Dependency**: Services relying on specific containerized environments (Docker, Kubernetes pods) - **Network Dependency**: Reliance on network protocols (HTTP, gRPC, message queues) ### D4. Semantic Dependency Semantic dependencies emerge from functional similarities between services. Services performing similar tasks may need coordinated updates to maintain consistency across the system. ### D5. Quality Attributes Dependency These dependencies relate to non-functional requirements: - **Security**: Authentication, authorization, encryption dependencies - **SLA Requirements**: Performance, availability, and reliability constraints ### D6. Requirement Dependency Functional dependencies based on business process flows, often mapped using Domain-Driven Design (DDD) principles. --- ## Dependency Symptoms (S1-S4) Beyond the primary categories, we identified **symptom patterns**—manifestations of underlying dependencies that indicate potential issues. --- ## Tools for Industry Practitioners Our review identified **20+ tools** for dependency detection and management. Here are the most useful ones organized by use case: ### Dependency Analysis & Visualization ### Root Cause Analysis & Fault Diagnosis --- ## Impact on Software Quality Our review examined how dependencies affect key quality attributes: --- ## Practical Recommendations ### For Architects and Team Leads 1. **Map dependencies early** — Use tools like GSMART or MicroDepGraph during design reviews 2. **Classify by criticality** — Distinguish hard vs. soft dependencies to prioritize resilience efforts 3. **Monitor coupling evolution** — Tools like SYMBIOTE can detect architectural degradation before it becomes critical 4. **Adopt interface-first development** — Define contracts before implementation to prevent hidden dependencies ### For Developers 1. **Avoid shared databases** — Expose data through dedicated services with REST APIs 2. **Prefer asynchronous communication** — Reduces temporal coupling and improves resilience 3. **Use feature flags for gradual rollouts** — Enables backward-compatible API evolution 4. **Implement circuit breakers** — Prevents cascading failures from dependency issues ### For DevOps Teams 1. **Integrate dependency scanning into CI/CD** — Catch issues before deployment 2. **Use observability platforms** — New Relic, Ortelius, or OpenTelemetry for runtime dependency tracking 3. **Containerize with clear dependency boundaries** — Explicit Dockerfile and Kubernetes manifests 4. **Automate dependency updates** — But with careful testing to prevent breaking changes --- ## Benchmarks for Testing The research community has developed several benchmarks for testing dependency-related tools: --- ## Open Challenges Despite significant progress, several challenges remain: 1. **Automated taxonomy application** — No tools yet automatically classify dependencies into our taxonomy 2. **Cross-language dependency detection** — Most tools focus on single languages (Java dominates) 3. **Runtime vs. design-time gap** — Static analysis misses dynamic dependencies; dynamic analysis is resource-intensive 4. **Semantic dependency detection** — Understanding functional similarities requires advanced NLP/ML approaches 5. **Quality attribute integration** — Connecting dependencies to SLA violations remains manual --- ## Citation ```bibtex @article{abdelfattah2025multivocal, title={Multivocal study on microservice dependencies}, author={Abdelfattah, Amr S. and Cerny, Tomas and Chy, Md Showkat Hossain and Uddin, Md Arfan and Perry, Samantha and Brown, Cameron and Goodrich, Lauren and Hurtado, Miguel and Hassan, Muhid and Cai, Yuanfang and Kazman, Rick}, journal={The Journal of Systems and Software}, volume={222}, pages={112334}, year={2025}, publisher={Elsevier}, doi={10.1016/j.jss.2025.112334} } ``` --- ## About This Research This work was conducted at the **University of Arizona** in collaboration with the **University of Hawaii** and **Drexel University**. Our team combines expertise in software architecture, microservices, and empirical software engineering. The paper has been **published in the **, a top-tier software engineering journal. The including all synthesized studies and extracted data is available on Zenodo. --- ## Appendix: Complete Tool Reference For practitioners looking for a comprehensive reference, here's the full catalog of dependency management tools organized by category. ### Dependency Analysis Tools ### Dependency Visualization Tools ### Supporting Frameworks --- ### Where It Started: My B.S. in Computer Science at Arizona **URL:** https://arfanu.com/blog/bsc-cs-uarizona **Date:** 2020-05-15 **Author:** Arfan **Description:** In 2020 I graduated from the University of Arizona with a B.S. in Computer Science, and the U.S. Embassy in Dhaka featured my story. A look back at the teaching, mentoring, and first builds that started it all. title: "Where It Started: My B.S. in Computer Science at Arizona", description: "In 2020 I graduated from the University of Arizona with a B.S. in Computer Science, and the U.S. Embassy in Dhaka featured my story. A look back at the teaching, mentoring, and first builds that started it all.", date: "2020-05-15", author: "Arfan", tags: ["Bachelor", "Computer Science", "University of Arizona", "Dean's List", "US Embassy", "milestone", "teaching"], alternates: { canonical: "/blog/bsc-cs-uarizona", }, openGraph: { type: 'article', title: "Where It Started: My B.S. in Computer Science at Arizona", description: "In 2020 I graduated from the University of Arizona with a B.S. in Computer Science, and the U.S. Embassy in Dhaka featured my story.", url: 'https://arfanu.com/blog/bsc-cs-uarizona', siteName: 'Arfan Uddin', images: [{ url: 'https://assets.arfanu.com/blogs/bsc-cs-uarizona/Arfan-Uddin-bsc-Celebration.jpg', width: 1280, height: 720, alt: 'Md Arfan Uddin, Bachelor of Science in Computer Science, University of Arizona graduation recognition', }], publishedTime: '2020-05-15', authors: ['Arfan Uddin'], }, twitter: { card: 'summary_large_image', title: "Where It Started: My B.S. in Computer Science at Arizona", description: "In 2020 I graduated from the University of Arizona with a B.S. in Computer Science, and the U.S. Embassy in Dhaka featured my story.", images: ['https://assets.arfanu.com/blogs/bsc-cs-uarizona/Arfan-Uddin-bsc-Celebration.jpg'], }, }; const isExternal = href.startsWith('http'); return ( ); }; "@context": "https://schema.org", "@type": "BlogPosting", "headline": metadata.title, "description": metadata.description, "image": ["https://assets.arfanu.com/blogs/bsc-cs-uarizona/Arfan-Uddin-bsc-Celebration.jpg"], "url": metadata.alternates.canonical, "datePublished": metadata.date, "dateModified": metadata.date, "author": { "@type": "Person", "name": metadata.author, "url": "https://arfanu.com" }, "publisher": { "@type": "Organization", "name": "Arfan's Blog", "logo": { "@type": "ImageObject", "url": "https://arfanu.com/assets/arfan.svg" } }, "keywords": metadata.tags.join(", "), "articleBody": "In May 2020 I graduated from the University of Arizona with a Bachelor of Science in Computer Science. During my undergraduate years I worked as an Undergraduate Teaching Assistant and Section Leader in the Department of Computer Science, mentored students for three semesters, made the Dean's List with Distinction in 2018, interned at Hexagon Mining, and started building software professionally. The U.S. Embassy in Dhaka featured my graduation as part of its #BDUSGrads2020 series celebrating Bangladeshi students graduating from U.S. universities.", "about": { "@type": "EducationalOccupationalCredential", "credentialCategory": "Bachelor's Degree", "educationalLevel": "Undergraduate", "about": "Computer Science", "recognizedBy": { "@type": "CollegeOrUniversity", "name": "University of Arizona", "url": "https://www.arizona.edu" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": metadata.alternates.canonical }, "isAccessibleForFree": "True", "inLanguage": "en-US", "articleSection": "Blog", "wordCount": "1050" }; ** with a **Bachelor of Science in Computer Science**. 🎓 It's easy to skip past the bachelor's degree once the fancier titles arrive. But the truth is that everything I value about how I work, teaching, building, showing up for the people around me, was forged in those undergrad years. So this is the post I should have written a long time ago. ## A graduation that traveled home A few weeks after commencement, something happened that I still find hard to put into words. The **U.S. Embassy in Dhaka** featured my graduation on its official social media as part of its **#BDUSGrads2020** series, celebrating Bangladeshi students who graduated from U.S. universities that year. > "Join us in congratulating Md Arfan Uddin!! 👏 He graduated from The University of Arizona with a Bachelor of Science in Computer Science. During his time at #UofA, Arfan served as an Undergraduate Teaching Assistant and as a mentor in the Department of Computer Science... for three semesters, and all while making the Dean's List with Distinction in 2018. Way to go Arfan!! As they say at The University of Arizona, #BearDown!" > > — **U.S. Embassy in Dhaka** For a kid who grew up in Bangladesh and crossed the world to study, having my home country's U.S. Embassy say *we see you* was surreal. It reframed the degree for me. It wasn't just my milestone, it was a small marker that the bet my family made on me had paid off. ## Dean's List with Distinction In **2018** I made the **Dean's List with Distinction**. I mention it not as a trophy, but because of what it represented: I had finally found the rhythm of college far from home, in a second language, while working on the side. The grades were the easy part to measure. The harder, better part was realizing I could carry a heavy load and still do it well. ## Teaching is how I actually learned The thing the embassy caption got exactly right is that my undergrad years were as much about teaching as about taking classes. I served as an **Undergraduate Teaching Assistant and Section Leader** in the Department of Computer Science. I TA'd **CSc 252** and led a recitation section of **37 students** for **CSc 210**, two hours a week, plus office hours, grading assignments, quizzes, and exams. Separately, I spent three semesters as a **departmental mentor**, running a **Raspberry Pi workshop** to get students excited about hardware and helping freshmen find their footing both academically and in their careers. Standing in front of a room and explaining pointers, recursion, or why their code segfaulted taught me something no exam could: if you can't explain it simply, you don't understand it yet. That instinct, to break hard systems down until they're teachable, is the same instinct that drives my research today. ## Building before I knew it was a career I didn't wait for graduation to start shipping. Two experiences stand out. I interned at **Hexagon Mining** as a Software Development Intern, where I rewrote the serializer for their MinePlane Schedule Optimizer (MPSO) in **C# and Json.net**. The rewrite ran roughly **2x faster** and used **2-3x less memory** on our benchmarks, my first real lesson that the way you model data is the performance. By my final semester I had joined **Hamilton Innovations** as a Full Stack Software Engineer, building frontends in **Flutter and React**, APIs in **Node.js (TypeScript)** with **JEST** tests, and designing schemas in **PostgreSQL and MySQL**. It was the first time I owned features end to end, from database table to UI. ## Giving back to the community that raised me Alongside all of it, I kept showing up for ****, our student hackathon. I ran workshops on **Android development with Dart and Flutter**, and helped find sponsors and organize beginner-friendly sessions so first-timers had a way in. Some of the people I mentored at those events went on to build things far bigger than mine. That's the whole point. ## What the degree set in motion Looking back, the bachelor's wasn't a finish line, it was the launchpad. The teaching became a lifelong habit. The internships became a craft. The community work became **** and **** years later. And the research instinct that started with explaining code to 37 students eventually became published work and a PhD. If you've , you know the path after this got winding, industry, an MBA detour, and finally back to Arizona for the PhD. But it all rests on this foundation. To my **family**, who sent me across the world and believed before there was any proof: this one was always for you. And to the University of Arizona, thank you for the start. **Bear Down.** 🐾 --- ## Contact & Links - Homepage: https://arfanu.com - Blog: https://arfanu.com/blog - LinkedIn: https://www.linkedin.com/in/rfn/ - GitHub: https://github.com/arfan-rfn - X/Twitter: https://x.com/arfan_rfn - Connecto: https://getconnecto.app --- End of document.