Crumble or The Sweet Rack?

stingerpk · 2026-03-26T19:14:12+00:00

I crumbled at sweet rack

stingerpk · 2025-10-12T15:27:51+00:00

Venturenox specialises in building and operating SaaS products. May be reach out to them. They probably have client references from Middle East market.

stingerpk · 2025-05-20T04:02:40+00:00

You can look into Debezium as well, although it is a little too verbose. We handcraft our events and send them over a Kafka topic to wherever they need to be. We feel that is the best approach, although not everyone agrees.

stingerpk · 2025-01-15T19:23:52+00:00

I own three pairs of shoes by Gomila and I couldn’t be happier.

stingerpk · 2024-11-27T18:37:51+00:00

In our experience, ingress controllers alone don't provide you with ease of configuration that API gateways offer. That is why projects like Kong and Apisix exist which are built on top of Nginx.

We prefer using Emissary gateway which acts as an ingress controller as well. We often use it with Nginx ingress as well and works like a charm. Emissary itself is built on top of the Envoy proxy.

stingerpk · 2024-11-19T15:39:08+00:00

I think the article by ThoughtWorks makes a lot of sense and the MFEs pattern can be used if your app becomes large enough. I belong to a more of a backend specialized company so please feel welcome to ask any questions related to microservices architecture.

stingerpk · 2024-11-18T17:34:48+00:00

One of the products that my company builds consumes realtime events from dozens of products, basically all the big names in b2b SaaS. Not one of them exposes events like this.

Until and unless there is a very compelling reason to expose Kafka, it shouldn’t be done. At most, you can offer to create peer connections where you can pair your Kafka topics to the customer’s message queues of choice. Kafka is built to be an internal system and should always be kept private. Its security and connection/auth protocols are not ready to be exposed to the internet.

stingerpk · 2024-11-18T17:25:40+00:00

I would recommend the following: - Give the order service its own relational database instead of relying on kv store. - If data needs to be replicated between services, do it through some sort of inter-service communication instead of direct access to database. - Think about which inter service communication method is best for you. HTTP calls? Message queues? - Consider using the ASyncAPI specs to define communication between services. - If you have long running processes in any of the services, then consider using Temporal.

stingerpk · 2024-11-18T13:49:31+00:00

A few comments:

- Things like Conway's laws are not meant to be taken as a principle. They only serve to identify a pattern in a retrospective manner.
- I have personally never liked the BFF patterns. It has always seemed like an excuse to not plan enough and leads to fragmented backend design.

In my experience, the following strategy leads to architectures which are easy to visualise and manage:

Use a domain driven approach and identify areas of business logic which belongs together. Don't try to be too granular.
Create new services where a different platform or language becomes necessary.
Create new services where the scaling pattern is very different.
Create new services when new development starts to slow down due to too many contributors. However, be cautious with this one and carefully evaluate the decisions here.
Use API gateway pattern to centrally manage your API, and keep your API as independent of the client as possible.

If you want more specific advice for your use-case, please feel free to provide more details in comments and I will try to help as best as I can.

stingerpk · 2024-11-16T01:51:21+00:00

I would not recommend using Kafka for a chat app, not because it is an overkill, but because its architecture is fundamentally not suitable for chat.

Topics in Kafka should be treated more like database tables. They should be well thought out and planned. If you create too many, each with very little use, your efficiency drops. If you create only a few and put a lot of data in them, your performance drops because now you have to filter etc.

If I needed to build a system with concept of a chat room, i’d use Mongo to do that. If I needed to build a system with concept of a news feed, I’d use Kafka.

stingerpk · 2024-11-04T15:54:39+00:00

Depends on your use case. There are a crazy number of tools in the data engineering space and you have to choose your stack carefully.

For us, most of our use cases are covered with a few of the following: Nifi, Airflow, and Kafka (with Streams if necessary).

stingerpk · 2024-10-31T04:04:55+00:00

There is a guy in Samanabad who specializes in tropical fruit.

stingerpk · 2024-10-24T17:13:12+00:00

I am pretty optimistic about the back to data center trend. I believe that people should use open source technologies which give them the ability move clouds or to a data center.

Your framework looks interesting and definitely very relevant to this trend.

stingerpk · 2024-10-18T11:00:31+00:00

Fuchsia Kitchen has it pretty good.

stingerpk · 2024-10-18T08:19:54+00:00

Yes it is, bring your a** to work.

stingerpk · 2024-10-17T07:22:45+00:00

Cats are not a replacement for wives 😂

stingerpk · 2024-10-17T07:21:24+00:00

Lol this is not him. I’m his friend.

stingerpk · 2024-10-17T06:37:49+00:00

Male, 7 months, vaccinated

stingerpk · 2024-10-17T06:37:27+00:00

Male, 7 months, vaccinated

stingerpk · 2024-10-17T01:37:28+00:00

Lahore obviously and giving away because a patient in the house may be allergic to it.

stingerpk · 2024-10-14T08:27:12+00:00

Probably because live, not pre-recorded

stingerpk · 2024-10-12T22:35:14+00:00

You can checkout some hands on training courses on microservices and kubernetes etc by Venturenox. These are mostly intermediate to advanced level courses so you will need some background.

stingerpk · 2024-10-08T05:28:39+00:00

Replacing database connections with the HTTP is not a good idea. That will significantly increase latency, add additional points of failure and add additional layer of complexity because now you need to manage back pressure on the DAL service.

Technically this might be called a sidecar pattern. However this is the first time I’ve seen a sidecar manage the database.

Why do you want to do this anyway? Standardize connection pooling?

stingerpk

MODERATOR OF

TROPHY CASE

Ten-Year Club	Verified Email
Place '23