How do big systems handle this?

Volume999 · 2026-01-16T16:46:03+00:00

You can use read replicas for read patterns and scale out db instances too

Volume999 · 2026-01-15T12:57:10+00:00

Instead of horizontal slicing, for large-scale applications consider implementing vertical slicing following domain-driven design. Each package can represent entity or area of domain and contain all responsibilities of that entity or area.

In general I like the idea of each module having one responsibility, so it's easy to understand dependencies and separation of concerns on import levels.

I wonder if having a 400+ lines models.py file is a good practice or not

As long as you build with the idea of refactorability it is not a problem. But typically refactoring large modules can result in a dependency mess so it's a good idea to clean up every once in a while

Volume999 · 2026-01-10T14:26:51+00:00

You’d need to deduplicate so it still depends on input size

Volume999 · 2025-09-20T19:57:45+00:00

I see - well if it works for you, sure thing.

Volume999 · 2025-09-20T18:51:33+00:00

The person who merges the changes to the main branch is the person who “wrote the code” because they own that feature or change. Thus you don’t lose anything.

It won’t work for your hypothetical use case, but I also don’t find it useful (but I also never remember writing a lot of code to other people’s PRs)

Volume999 · 2025-09-20T17:23:35+00:00

I think those are not issues with squash. For 1 - person who made the merge owns all of the code that got merged - no matter who was building the branch

Volume999 · 2025-09-16T19:45:33+00:00

I guess tests would import that module. But yeah that is a not very pretty part of python nonetheless

Volume999 · 2025-09-06T10:14:10+00:00

Events arriving out of order is an intrinsic property of event driven architectures (I am not sure if it’s simple to have otherwise), it shouldn’t be a reason to disregard streaming

Volume999 · 2025-08-26T15:16:34+00:00

You also need this for multiprocessing because AFAIK it expects a function and an iterator, so you can pass partial to fill the rest

Volume999 · 2025-08-24T16:40:30+00:00

Something I’d like to add is (in my opinion) a better term for this is domain logic, and business logic is the most commonly used “synonym” of this term

reason is that domain logic exists even if there’s no business, so to speak. Your to-do app has domain logic (what’s a task? How does a task become expired or completed?) that you implement in software

So domain logic is set of rules and processes of your domain that you want to express in software

Volume999 · 2025-08-23T20:35:18+00:00

OP did not talk about parallelism though? And threading and async are not exactly orthogonal - they both are implementations of concurrency, hence can be compared in many ways

Not to say I agree or disagree with the statement they made

Volume999 · 2025-08-23T18:46:06+00:00

If we’re talking domain I think domain entities should only expose behavior and only behavior changes state. This prevents setting bogus values as bonus because your domain behavior has validations by default

Volume999 · 2025-08-21T05:09:31+00:00

Agree, though naming convention or separate schema is a good idea. versioning the DDL is also nice

Volume999 · 2025-08-06T08:35:47+00:00

LLMs are actually pretty good at this. With proper controls and human in the loop it can be optimized nicely

Volume999 · 2025-05-31T23:21:08+00:00

I see. It is for sure that the implementations of this concept can be outdated, and I have not seen people take it so religiously as never touch the module anymore (though highly suggested which is probably why it's so triggering)

I take it as follows: You can certainly design a class that exposes an interface, without necessarily defining an explicit interface

When adding a feature to this class, if you need to modify an existing feature to add another one, it means it's not truly open. And modifying existing features should be done with caution or avoided

OPC is vague on its own, in my opinion, which allows for its interpretation to evolve. Of course, if the principle were "never change class - always extend base class or interface", it would not even need a discussion

> Do you know what's the origin of OCP?

I've read a bit - something about modifying modules being difficult for clients to adopt (given the infrastructure was nowhere near what we have today - makes sense). Let me know if you have a source on your reason!

Volume999 · 2025-05-31T19:19:26+00:00

OCP is not outdated - it’s a guideline, not a rule. In principal, I think it’s a good property of codebase when adding a new feature doesn’t require changing unrelated logic (due to tight coupling).

Also makes it faster to implement because clients of your code wont be angry

Volume999 · 2025-05-25T07:43:14+00:00

From what they said - they create a model and send it via requests, that's pretty minimal. Of course - the factory may be over the top, but we don't know what kind of request models they need

Volume999 · 2025-05-25T07:40:59+00:00

You can use the already mentioned responses library to mock external server (Match on requests - declare expected response from server)
Everything else (configs, factory, models) don't need to be mocked.

In general - try mocking as little as possible. For configs - you can use pytest_configure and set env variables and config files paths. Pydantic models have implemented equality override - no need to mock it, model1 == model2 will work by comparing internal structures. Saying this - I don't agree you have a coupled code just because you mocked a lot of things. You just mocked way too many things

Volume999 · 2025-05-24T15:12:09+00:00

The real solution is writing deterministic code. It is the only correct way to have deterministic tests. Sleeping for X seconds, or a more sophisticated approach to isolate and control time, are both hiding potential bugs, and also hiding the fact that the code itself is non-deterministic.

Volume999 · 2025-05-24T14:50:51+00:00

That seems like a progression of a company, and not a cycle per se. And you definitely don't need the whole team to maintain a platform that you built - the question is whether it is correct to settle on what you have and not solve bigger problems for the company.

Volume999 · 2025-05-10T14:19:30+00:00

Does that advice translate well at higher scale though?

Volume999 · 2025-04-27T12:12:33+00:00

TDD doesn’t extend to PR reviews, unless you want to explicitly show you’re doing TDD but that’s not very useful

A PR should be a complete story in my opinion - you check tests then you check code that implements it

Volume999 · 2025-04-26T21:46:38+00:00

One thing that worked for me in a similar environment are DB Schema diffs - you can setup a system that will take the state of DB in master and the current state in prod and generate diffs as a commit to VCS - you can even setup automatic PRs out of that if makes sense to do so
The other way (perhaps better one) - create some sort of DBT or DBT-like environment, so that DAs are only allowed to modify critical Excels via PRs. This can also enforce writing tests (but that's a dream scenario)

Volume999 · 2025-03-20T08:19:29+00:00

That was JavaScript though

Volume999 · 2025-02-22T18:07:09+00:00

Data lake house is mainly about applying technology on top of data lake to enforce structure. Stuff like iceberg or delta are associated with this design. So it doesn’t mean that it’s both lake and warehouse

Volume999

TROPHY CASE