@brankopetric00 Improve pipeline time to no more than 20 minutes, improve deployment time to no more than 5 minutes.
20 engineers is not a big team to not be able to handle a monolith. When getting to 20 and still growing plan splitting some components.
I think that probably it's still worth, as it will make it easier for AI to understand it in the future.
But maybe make it less strictly: "If a method exceeds 20–25 lines or encompasses multiple responsibilities, consider whether splitting it would improve readability and maintanability."
Card payments knowledge:
In the past 5-10 years, card schemes have created rules about how retries should be performed, and penalize merchants and acquirers if not following them.
There are errors codes categories for when:
- a retry should never be performed or allowed.
- a retry should be performed maximum 15 times in a 30 days interval (ex: insufficient funds)
- a retry is allowed but only by user, not automatically; and the error for frozen card is probably here.
@benjamincrozat Why die? Better let people try it in multiple ways and see what was better on the short term vs on the long term. Too bad the feedback loop is that large.
I feel is all about the difference in what is expected: high speed for time to market vs scalability for long term cost.
At some point, we decided (and I agreed) to convert all enums to varchar.
But now we got to a table, that is mostly a key-value store, that got to about 800GB and it could be reduced by 25% if a column would have been an Enum.
Also the table is in the top when doing performance tests and profiling and would benefit from some perform improvements.
Now that there is a good database migration and enough tests, switching back to Enum is feasible.
If you fear future conflicts, just make sure adding a new case to the enum is always using ALGORITHM=INSTANT, that will fail in case of conflict (when not just adding new possible entries).
@pronskiy@levelsio@official_php@ThePHPF Yes, maybe it's time for Ondřej Surý and Remi Collet to join @ThePHPF.
If PHP would have some official repositories to be installed from, it would look better for the language.
And beside production we need to keep in mind also the local development environments.
There are few ways to handle it:
1. Have a distinct status for a just created order, and after validating and reducing the stock, update the order by calling the order service again.
2. Have a functionality to reserve the items before creating the order by calling the inventory service, and after creating the order make another call to fulfill that reservation, or cancel it in case order creating fails.
Now writing all these, indeed it seems like a classical distributed system problem.
@matthieunapoli@fideloper Nope, actually, little changes are required to current frameworks if every request executes on a separate fiber, and all currently blocking I/O functions would suspend to an event loop. And I think there is a way to build this into PHP itself, probably in PHP 9.
@thel3l In my experience with various providers, the redirect urls are designed and used mostly for UX, and are not meant to control the internal transactions flow.
I believe there are some other server to server communication happening between the merchant and payment provider.
@thel3l Just asking to understand.
Aren't these callback urls the one you would be redirected back to the merchant after the payment, in the browser?
And if so, can't you just intercept the redirect and, instead of redirecting to fail url, redirect to success url?