iiinova — where your digital self keeps evolving

Kanishka Naik @kanishkanaik.dev · 21/09/2026

Point-to-point is contrasted with publish-subscribe, where a producer sends messages directly to a single consumer rather than broadcasting. In fintech, it fits tasks like fraud checks where duplicate handling must be avoided.

000

Kanishka Naik @kanishkanaik.dev · 21/09/2026

This pattern supports two delivery modes: unordered, for maximum throughput with multiple workers processing in parallel, or strictly ordered (FIFO), when sequence matters for business correctness, such as ledger updates.

101

Kanishka Naik @kanishkanaik.dev · 21/09/2026

Point-to-point creates a direct, exclusive channel: once a consumer takes a message, it's removed from the queue for everyone else. This exclusivity supports strict, one-time processing of financial transactions. #Fintech #DistributedSystems #Architecture

100

Kanishka Naik @kanishkanaik.dev · 21/09/2026

Cloud queues add durability: AWS notes queues buffer messages when a consumer is unavailable or needs a controlled processing pace, with messages persisting until explicitly deleted after successful processing.

000

Kanishka Naik @kanishkanaik.dev · 21/09/2026

Oracle's JMS documentation notes that when several receivers access one queue, message distribution is load-balanced across them rather than duplicated, so each message still reaches only a single consumer.

100

Kanishka Naik @kanishkanaik.dev · 21/09/2026

Multiple senders can post to the same queue, and multiple receivers can share a connection to consume from it. Load balancing among receivers accounts for each consumer's capacity and rate. #Queues #Messaging #Fintech

100

Kanishka Naik @kanishkanaik.dev · 19/09/2026

AWS describes point-to-point messaging as producers sending messages typically intended for a single consumer, most often implemented using message queues as the broker. This suits fintech tasks like processing one transaction exactly once.

100

Kanishka Naik @kanishkanaik.dev · 19/09/2026

The JMS specification defines this domain with queues as the destination: senders produce messages to a queue, receivers consume from it, and each message is consumed by only one receiver, even with multiple receivers attached.

100

Kanishka Naik @kanishkanaik.dev · 19/09/2026

Point-to-point messaging sends each message to exactly one consumer through a queue. A sender places a message on the queue; one receiver retrieves and removes it, unlike broadcast-style patterns. #PointToPoint #Messaging #Fintech

100

Kanishka Naik @kanishkanaik.dev · 19/09/2026

In event-driven architectures, pub/sub messaging infrastructure tracks subscriptions and pushes each event to every subscriber once, without replay. This differs from event streaming, where events sit in a log consumers can read at their own pace.

000

Kanishka Naik @kanishkanaik.dev · 19/09/2026

A key trade-off: publishers can't confirm subscribers are listening. Messages are typically transient, so an offline subscriber can miss events unless the broker adds durability features like message retention or replay.

100

Kanishka Naik @kanishkanaik.dev · 19/09/2026

Pub/sub fits scenarios needing parallel processing, broadcast to multiple subscribers, and tolerance for eventual consistency. It suits fintech workflows where one event, like an order fill, triggers several independent reactions. #Fintech #Architecture #DistributedSystems

110

Kanishka Naik @kanishkanaik.dev · 19/09/2026

Cloud implementations vary: Azure Service Bus topics support subscriptions with SQL or correlation filters, while Azure Event Grid focuses on push-based event notifications. Both implement the same underlying pub/sub concept for routing messages to interested parties.

000

Kanishka Naik @kanishkanaik.dev · 19/09/2026

Subscribers can filter what they receive. Topic-based filtering delivers all messages on a subscribed topic, while content-based filtering delivers only messages matching subscriber-defined criteria on the message's attributes or payload.

100

Kanishka Naik @kanishkanaik.dev · 19/09/2026

In pub/sub, publishers send messages to named channels called topics. A broker routes each message to every subscriber registered on that topic, without publisher or subscriber knowing about each other. #Messaging #EventDriven #Fintech

110

Kanishka Naik @kanishkanaik.dev · 29/08/2026

Pub/sub differs from point-to-point messaging, where producers send directly to a single consumer. In pub/sub, a message can reach many subscribers at once, which suits fintech events like a payment status change that several downstream services need to react to.

000

Kanishka Naik @kanishkanaik.dev · 29/08/2026

AWS design guidance describes pub/sub as separating concerns: applications focus on their core capability while the message infrastructure handles routing and delivery. This offloads responsibility for message delivery from the sender, improving scalability and responsiveness.

100

Kanishka Naik @kanishkanaik.dev · 29/08/2026

Publish-Subscribe (pub/sub) is a messaging pattern that decouples publishers from subscribers through a broker. Publishers send messages without knowing who receives them; subscribers get only messages matching their interests. #PubSub #DistributedSystems #Fintech

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Clients can supply an Idempotency-Key header on the initial request, so a duplicate submission returns the existing status resource instead of starting a second work item, per the same official guidance.

000

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Azure Architecture Center recommends exposing a DELETE operation on the status resource so clients can cancel a long-running request, with the back end updating the status once cancellation is handled.

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

This pattern also has to plan for cancellation, retries, and cleanup, not just the happy path of request, poll, and result. #Fintech #DistributedSystems

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

The 202 response should also include a Retry-After header with an estimated completion time, which helps polling clients avoid sending too many requests to the status endpoint while work is in progress.

010

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Per Azure Architecture Center, the status endpoint returns HTTP 200 while the work is still pending, and eventually returns a completion resource or an HTTP 303 redirect once the whole operation finishes.

110

Kanishka Naik @kanishkanaik.dev · 13/08/2026

The client makes a synchronous call, and the API replies right away with HTTP 202 Accepted plus a Location header pointing to a status endpoint to poll. #Fintech #APIDesign

110

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Microsoft's guidance notes many of the same considerations apply to server-to-server calls in distributed systems, such as a microservices architecture, and not only to calls made directly from client applications.

000

Kanishka Naik @kanishkanaik.dev · 13/08/2026

It exists because some back-end work takes seconds, minutes, or even longer periods of time, so waiting on the same connection is not feasible, even though most APIs otherwise reply in about 100 milliseconds or less.

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

The Asynchronous Request-Reply pattern decouples a long-running back-end task from a front end that still needs a clear response, per Microsoft's Azure Architecture Center. #Fintech #CloudPatterns

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

This constraint means Fire-and-Forget is best reserved for cases where confirmation of receipt or successful processing is not required at all by the fintech service that originally sent the message out.

000

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Enterprise Integration Patterns explains that in this situation, the recipient can route the bad message to an Invalid Message Channel, since it may not even know who the original sending Originator was.

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Because the recipient has no channel to send feedback, a message that cannot be processed has to be routed elsewhere rather than reported back to the sender. #Fintech #Messaging

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

In a fintech context, this suits scenarios like broadcasting a notification to several interested services without requiring every single one of them to send a reply back to the original sending party.

000

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Enterprise Integration Patterns notes these messaging systems typically implement Guaranteed Delivery, so a message is not lost even if the receiver, or the messaging infrastructure itself, is temporarily unavailable.

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

On local networks, Fire-and-Forget messages can travel over UDP, while most messaging systems, such as JMS-compliant brokers, provide this style by default. #Fintech #DistributedSystems

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

It works best over asynchronous channels, since the Originator does not have to wait for the message to be delivered and can move on to other tasks as soon as the messaging system accepts the message for delivery.

000

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Enterprise Integration Patterns describes this as the simplest conversation pattern: an Originator sends a message, and a Recipient receives it, with no further exchange required between the two parties.

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Fire-and-Forget sends a message to a recipient without expecting any response back. It exists for simple notifications where no reply is needed from the receiver. #Fintech #Messaging

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

If the reply message is not self-contained, the requestor has little choice but to discard it, which is why correlation identifiers and self-describing replies matter so much in this messaging pattern.

000

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Enterprise Integration Patterns notes this can happen if a message queue holds a leftover response from a client that crashed before consuming it, and a restarted client later reads that stale, unrelated message.

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Because request and response messages can travel over separate channels, a requestor may receive a reply out of order, or even one meant for a request it never sent. #Fintech #SystemDesign

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

The requestor can wait for the reply synchronously, blocking like a Polling Consumer, or process replies asynchronously as they arrive on the shared reply channel, depending on how the overall conversation is designed and threaded.

000

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Enterprise Integration Patterns explains this lets a single reply channel and a single reply-processing thread handle replies for multiple outstanding requests at once, instead of opening a new channel per request.

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

A Return Address in the request tells the replier where to send the reply, and a Correlation Identifier tells the requestor which request a given reply belongs to. #Fintech #Messaging

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

The request channel can be point-to-point or publish-subscribe, but the reply channel is almost always point-to-point, since a reply should return only to the original requestor and not be broadcast further.

000

Kanishka Naik @kanishkanaik.dev · 13/08/2026

Enterprise Integration Patterns defines two roles: the Requestor sends a request and waits for a reply, while the Replier receives that request and sends the reply back on a separate, dedicated channel.

100

Kanishka Naik @kanishkanaik.dev · 13/08/2026

The Request-Reply pattern sends a request message and a reply message, each on its own channel, so a one-way messaging exchange becomes a two-way conversation. #Fintech #IntegrationPatterns

100

Kanishka Naik @kanishkanaik.dev · 12/08/2026

RegTech sits at the intersection of fintech, compliance, and engineering. KYC, AML, sanctions screening, risk scoring, and real-time monitoring turn complex regulations into scalable systems. #RegTech #FinTech #AML #KYC #SoftwareEngineering

000

Kanishka Naik @kanishkanaik.dev · 11/08/2026

Accounting & CFO Tech is evolving beyond bookkeeping. 🚀 From ledgers and payments to payroll, tax, reconciliation, and reporting—modern finance platforms are becoming real-time financial infrastructure for businesses. #Fintech #CFO #Accounting #FinanceTech #SaaS

020

Kanishka Naik @kanishkanaik.dev · 01/08/2026

Microsoft's guidance advises against mixing synchronous HTTP with message-based communication once a service starts sending commands or events asynchronously, in order to keep the interaction model for that service consistent.

000

Kanishka Naik @kanishkanaik.dev · 01/08/2026

Enterprise Integration Patterns notes that asynchronous calls and callbacks can make a design more complex than a synchronous approach, since the caller must handle eventual confirmation rather than an immediate answer.

100

Kanishka Naik @kanishkanaik.dev · 01/08/2026

Asynchronous designs trade immediate answers for resilience: a call can be retried until it succeeds, but the sender no longer knows the outcome right away. #Fintech #DistributedSystems

110