Abhishek Bande

Could you help me understand more about your background by giving a brief introduction of yourself? Not sure whether recording has started or not. Alright. Anyways, yeah. I'm Abhishek Bande. I'm having, like, uh, eight plus years of experience specializing into distributed systems. I would integration scalable back end architecture or the, like, couple of years. I have led the design and implementation of microservices based platform using Node JS, Nest JS with, like, PostgreSQL as a primary database. I have hands on expertise, like, on expertise and uh, you know, experience working with, like, messaging, uh, systems like Kafka, RabbitMQ, and MQTT for building real time event driven systems. I'm also family with, like, LoRaWAN protocols for, like, low power IoT communication and have, like, designed end to end pipelines that integrate each devices with, like, cloud infrastructure on AWS using some services like s three API gateway and then I would record as well. So recently, I've been focusing on applying some event processing architecture design patterns to build scalable fault tolerant and IOT ecosystem that can handle the high throughput telemetry data while ensuring the mental ability and the observability as well. So in short, like, I enjoy solving, like, complex architectural challenges, mentoring team members, and staying up to date with, like, modern design patterns and cloud native practices as well. So I'm currently looking to take on, um, some of the, like, principal engineer or tech lead role where I can lead system design efforts and make architectural decisions and drive technologies, STG, um, aligned with the business tools as well.

How would you optimize a Kafka or a RabbitMQ consumer in a microservice environment where IoT devices are constantly streaming data? Well, okay. So optimizing Kafka and RabbitMQ consumer in a microservice IoT is, like, requires kind of an very careful attention to scalability through poor and fault tolerance. So so what I do is, like, I first have, like, for Kafka, I'll be having consumer configuration for throughput and parallelism. So I'll increase the consumer group parallelism and use the multiple consumers in the same group of, like, uh, parallelism consumption, then I'll tune the phase dot min dot bytes or phase, um, uh, phase dot max dot wait dot m s balance between the latency and throughput. I'll use the max dot poll dot records wisely to prevent, like, processing overload by limiting the number of message pools, or I'll ensure, like, topic partitions are evenly distributed across the consumers. And, uh, I'll also, like, ensure that to avoid the duplicate in case of, like, retries. For rapid MQL, I'll use prefetch, which is, like, I'll set, like, basic dot, um, QA's, like, prefetch count and and to control message flow and avoid the memory pressure as well. Also, like, uh, for multiplex consumer threads on a single connection for an efficiency, so where multiple channels per connections, you can say. I'll go for, like, manual HCM mode where allow, uh, the try or the data from failure while you're giving control over the live as well. I'll distribute workload and avoid some bottlenecks on a single queue as well. And for message processing optimization, I'll go for, like, a a synchronous processing using the worker pools or some task queues inside the consumer, microservices. I'll group on microservices and, uh, processes, uh, for an IoT message in batches if, like, order is critical. I'll also monitor the downstream DB APIs and apply rate limiting for an before management as well. I'll add exponential back off with the teacher and, um, some timeouts or try policies, and, uh, I'll use, like, some, like, c s slash bull or the lens for j as well. For scaling and fault tolerance, I'll use container orchestration like Kubernetes plus based on the CPU and custom metrics like, uh, Kafka lag, Alice Prometheus, Grafana, or Kafka UI tools to ensure consumers keep up. I'll redirecting the failed message to deal queue for later analysis or reprocessing. I'll also ensure add important processing logic so that, um, like, any duplicate messages don't incur up the state, and I'll use the correlation ID for on, uh, or deduplication IDs in the messages for tracking and retrypivish. And, uh, I guess that's it. Like, so to optimize all this, like, I focus on horizontal scalability, uh, back pressure filing or kind of an handling of those things and parts in aware consumer parallelism and add important processing, some resource efficient patterns. And, additionally, um, it's crucial to maintain that pipeline that can observe the telemetry buzz while ensuring delivering Oh,

What steps would you take to identify and fix performance bottlenecks in a microservice architecture? So, um, in order to, uh, over okay. Identify and fix performance bottlenecks. Okay. So there are a couple of things. So I I'll I'll be I'll take, like, some systematic and kind of a layered approach you can see. First, I will establish the observability first. So before optimizing, may I make the system my system is observable. So so I'm using some distributed tracing or centralized logging or metrics collection and then service mesh observability as well. Then I'll also isolate the bottleneck. So once I observe my observability is in place, then I'll look into the highlights and points, like, tracing them back to specific services or DB calls, and then we'll go for, like, checking the consumer log by Kafka and RabbitMQ indicates, like, some slow consumers as well and identify, like, some overloaded services as well and, uh, some high CPU memory or maybe kind of a network IO as well. So there will be some slow database queries, which I'll look for, like, some n plus one queries of missing indexes as well and then excessive locking or some retries under the load as well. That card might be in problem here. And to optimize the bottleneck, I'll go for an, um, for an application layer, I'll go for profile code. And on Node g side, like, I'll inspect, uh, like, using, like, cleaning dot g s or x, uh, node and maybe for nest g s built in profilers as well for cache reputed computations or API responses. I'll go for release and in memory and avoid synchronous and blocking code and, like, smarts in from work like Node. Js For database end, like, I'll add indexes. I'll use connection tools. I'll avoid chat DB calls, so making heavy reads to the cards. On a network side, I'll go for enabling the compressions using DG port deflate, or I'll use HTTP two or gRPC for low latency. I'll reduce the payload sizes and enable request level caching as well. For messaging layer, I'll go for using Kafka or queue, which gives, like, consumers don't have prefetch for different poll settings as well. So I'll ensure that and, uh, retry logic, which doesn't amplify the pressure. I first level, I'll go for, like, setting up the proper in front, uh, having, like, auto scale services using Kubernetes, HP, and, uh, some cloud auto scaling services or groups as well. And I'll place the, uh, latency sensitive So it was just closer to whether, like, with the zone replacement as well, and then I'll tune resources limits and then, uh, request in different Kubernetes as well. So, um, I'll I'll also use, like, passing patterns then, uh, for refactoring. They come long and fat services into smaller units if needed. And then this I'll this I'll go for, like, kind of an whenever applying long term fixes for that. So applying rate limiting, throttling, bad pressure, leveraging the code, or maybe some edge edge caching or maybe some adding some service measures or, um, yeah, that's pretty all.

How would you work with other architects on the same project? Well, um, yeah, this has been scenario in, like, my current project as well where, like, working with, like, other architects on the same project requires, like, strong collaboration and clarity and, like, system thinking approach to ensure, like, architectural consistency perform and kind of long term and durability as well. So I'll align my goals and ensuring we will understand the business and technical objectives, scalability, like resilience or time to market. And I'll define the guideline principle, like, for example, even to an architecture or cloud native or 12 factor apps, and definitely security first things. Then I'll choose a shared, uh, vocabulary. I'll use, like, a grid terminologies and architecture documentation standard. So I believe in defining a common architecture language and decision frameworks of front to reduce, like, ambiguity and design drift as well. So, uh, I'll I'll also divide the responsibilities with the ownership. So I'll split architecture by domain by, uh, for example, IoT. We have IoT ingestion, API layer, storage, observability. I'll assign system boundaries and give autonomy to Windows subsystems, and I'll go for using some design governance and, uh, system mechanism kind of and things where sync mechanisms will work. So weekly, biweekly, architecture usually sync up to discuss the design changes, integration impacts, or some performance considerations as well. Mentoring version architecture documents using confluence and other stuff as well. I'll also involve, like, other architects certainly using, like, mobile boarding or collaborative tools like Miro or, um, we have loose lucid charts as well. So co create POCs and API contracts before handling them off to the teams and, um, ensuring design reviews are not being, like, what's left, but alignment checkpoints. Then coordinating on the cross cutting concerns, I work with, like, other architects who define some shared standards for security, observability, and then we also have, like, auto scaling, resilience, DevOps teams, and then some data story as well. So I'll host internal tech talks and roundbacks to share architecture insights and listen, learn as well. I'll mentor senior engineers to grow future architects. So these are things I usually do.

Uh, below is a Node JS code snippet that attempts to implement a binary search algorithm on the sorted array. There is a subtle bug in the implementation. Please review the code and explain the issue along with how you would correct it. Okay. Let's start. Let's start and then do made So with the binary search that we have is mostly with the So, um, what I see is that, uh, in the line of, like, where we, uh, the, uh, line we have, uh, the letter and is equal to. So we are setting the end to which is, like, one index beyond the variant range in JavaScript. So zero index. So what we need to do is that, uh, we need, like, to have, like, a dot length minus one. That's something we need to do. So, um, yeah, that is the only issue I see. And, um, using a dot length allows, like, to mid exit the valid index range, and it leads to comparison with, like, undefined and causing failures to find valid targets at the end of the area as well.

Okay. How would you design a system handle certain x increase in device traffic without impacting performance? Okay. So so let's say, like, uh, if we wanted to design a system that will, like, handle device traffic efficiently without, like, impacting the performance. So we need to have, like, our system to be asynchronous event to one and kind of on scalable architecture that is separate. So the clear critical pass and from, like, heavy lifting task. So, uh, uh, first of all, like, we should be having some need to define, like, critical versus, like, some noncritical activities. So critical activities are, like, kind of the things that must have processed in a real time, like device authentication or telemetry arts or heartbeat site, And kind of a non critical alerts or activities are, like, heavy and delayed access, like analytics, aggregation, and any kind of, like, logging or some enrichment backups. So the architectural overview of, like, I'll be having, like, first, I ordered devices, and then it would be having, uh, trigger with the API gateway or MQTT broker or some ingestion layer. And then it will be going for real time processor of layer validators or filters and routes, and then it will go for, like, um, passing queue, Kafka. And, uh, from there, it will go for Kafka or RabbitQ or MQ or maybe AWS IoT rule. And then, uh, post that, it will go for, like, uh, having some immediate actions, like background workers or maybe some analytics things as well. So, uh, first of all, uh, asynchronous offloading via messaging is, like, something using Kafka and traffic, m p two q with noncritical workloads, like data storage and analytics and some enrichment as well. For an event, even architecture will even process, like, Afghan AWS or even braces, right, to decouple the traces, and I will return consumers for logging as well. And for real time parts should, like, always say, like, lean, so only roots alerts or threshold or critical device controls, messages in a real time execution part. I'll also, like, leverage edge processing if applicable wherever there is. And I'll pushing, refiltering, throttling, and even basic, like, um, ML scoring to edge gateways or device from here as well. For scalability, I'll go for auto scale microservices using Kubernetes, HP, and Fargate or some back pressure handling is like using refresh on max dot cold or records or for for cold parts or heavy jobs, long running, or kind of uncomfort heavy tasks. For example, we have, like, model training or reporting. It should go into, like, batch processing batch as well. For monitoring and failsafe mechanism, we have deal queues, certain breakers, and structure logs, some metrics as interesting as well.

How would you build and manage a team in APAC? Considering the diverse region and their unique challenges, where would you start? Alright. So I guess this is not my first project where I have managed. So building and managing software engineering teams in an so specifically, like, a CCS specific region. So it requires, like, thoughtful approach and that balances regional diversity and culture answers as well. Sometimes those issues and varying varying the bachelor of, like, software engineers or leaders as well. So I'll start, uh, with the purpose and local context, like having understanding the business goals and regional context. So are we building some RND up or kind of a delivery center or support team or maybe kind of a new product or maybe in, uh, local market? So I'll tell her the team design based on the market and maturity, and then, uh, uh, we'll go for, like, having some map mapping the regional strengths like India, Vietnam, Philippines. So it's, like, having strong delivery and talent pipelines. And then, for example, Singapore, Japan, and Australia, we have, like, some product design and having, like, tech leadership, regulatory sensitive leaders as well. And we need to, like, build the right team structure first. So hybrid model, I would prefer for where to start with, like, core team member of senior engineers local or relocated who set the foundation and add local hires and, like, junior talent gradually with balances of experienced mentors. And engineer manager or tech leads usually having, like, our back end and front end developers, dev ops, product owners, and then, uh, recruit, you know, strategically and then region wise of the trends that we should have. To partner with, like, local universities and some bootcamp hiring interns or using, like, regional tech teams. And we will start establishing in a strong cultural foundation for them, like, posting the inclusive culture, respecting language barriers, and certain, like, cultural holidays, other stuff. Right? I'll I'll get, uh, always, like, encouraging you one on one with, like, skip levels and using collaborative tools. So, uh, we would be need to handle the time zone diversity. So establishing core overlapping hours, like, three to four hours of, like, uh, hours of a day. Uh, we should be collaborating with each other and overlapping with each other. We use, like, a follow the same model for supporting and hands off when needed and ensuring the communication as well, like weekly sync or async updates or daily Slack or everything. So and we'll go for documentation first mindset. Right? Everything that you might think of on, uh, investing in a growth and kind of on retention. So for that, I'll go for mentoring the different programs with, like, global counterparts and deliver tech talks, workshops. I'll start adopting the attack specific challenges, like, maybe if we have any, uh, kind of ambiguity or compliances. So yeah. So anyway, we need to align the team, um, with the purpose and regional sense with that as well.

What strategies would you use to ensure that messages between I o d devices and microservices using RabbitMQ are processed in order despite network hiccups? So I don't really use the issue that message. Okay. So yeah. First of all, uh, I'll leverage message grouping by some routing key or queue. So use one queue per device or device group logically, sharding, ensuring all messages for a, um, maybe given device go to the same queue, and then this ensures if you're for ordering within the ether device scope. I'll use, like, prefetch is equal to one to enforce strict serial processing, and I'll configure the rapid m q consumer with the channel dot prefetch one to process only one message at the per consumer, which preventing message being pulled and processing in parallel, which can cause out of order execution as well. And, uh, I'll use publishers confirms on the RabbitMQ predecessors to ensure the broker has issued and processed the message. I will use, like, manual acknowledgments from, like, consumers only of pre processing. Uh, even with, like, stick ordering or network hiccups or resets can, like, lead to retries or duplicate deliveries as well. So while I ensure microservices are important, processing the same message multiple times should reproduce the same output. And leveraging the messages time stamps and sequence numbers slow, I'll include the sequence numbers and the, uh, message payload from the IO devices so consumer service can detect out of order messages or buffer messages until the missing one error is. And alerting, like, uh, for dropped out or maybe out of order packets or implementing deal queues and the trap policies. So and avoid some blocking, uh, the pipelines due to the bad queue. And we should be using DLQ for, like, kind of an error handling and kind of stuff like where we might need to implement the other things. So we'll go for some okay. Yeah. And for, uh, for, like, for partial ordering or when, like, full ordering isn't scalable. So in that case, full ordering across all the messages doesn't scale well. So use the partitioning by device groups, maintain the local ordering when needed, and allows the concurrent preprocessing under for the underutil device types as well. So, yeah, that's pretty all.

Can you explain how you would implement an event driven system using Kafka or RabbitMQ? Uh, fortunately, yes. Because, uh, that's, like, somewhere I have set up these things multiple times. So, uh, first of all, I'll go for defining domain events, like start identifying the some domain events in the system. For example, device generated or maybe some sensor data received or some threshold exceeded or other triggers. So for each event, should be mutable and, uh, which should be presented some something that has already been happened. Right? So I'll choose the right broker for that. So I'll using Kafka when you need an high throughput and, uh, you want to reply, uh, some maybe so you if you want to have, like, some, uh, replay messages or some retain retaining them for the analytics, you want, like, some stronger ordering guarantees, poor partition, or use RabbitMQ for like, you need to, like, some low latency and real time communication or when you need, like, some complex routing via topic or other exchanges or you need, like, poor message acknowledgments and dead lettering things. No? For a producer, each microservice or IoT gateway publishes events or to Kafka topics or rapid app exchanges. So I'll use serialized formats like JSON, Protobuf, or Avro. I'll add metadata, headers, like, time stamps, host device, collision ID. For the consumers, like, I'll use Kafka consumer groups or RabbitMQ, uh, queues to distribute load. I'll then maybe consumer process the different events asynchronously and perform the business logic. I'll make sure to, like, acknowledge the processed messages, handle bit drives gracefully, and use item potency to avoid the duplicates. For a microservice integration, I'll my concern, like, each microservice subscribes to the events it's interesting to And, uh, use event routers and even even gateway like Kafka, Teams, and Nextiva's. Like, we have some event bus. What else? I guess oh, yeah. Again, like, if you want me to talk about the scalability and fault tolerance, so I'll consider it after for, like, when we use, like, multiple partitions of, uh, for, like, high throughput or deploy the replication and acknowledgements to all and durability as well. And I'll also go for, like, Kafka for streams for, like, stream processings and then Rabbit MQ, I'll go for using FAQs or enabling some messages, persistence, and publisher confirms. And they'll, uh, go for, like, RabbitMQ and, like, uh, use prefetch limits to manage the consumer load. So, yeah, that's pretty on.