Sync vs. Async. I have been thinking this to myself and have involved quite a few discussions with smart (and mostly young) developers which from time to time makes me wonder whether there is a definite answer for this at all.
One thing I can fairly state is that there isn't a right or even an answer. It depends. Yes, it depends on what you mean by sync or async, and why you care about one way or the other. The discussion isn't technical, it isn't philosophical, it is to understand use case, user's expectation, workflow, execution sequence, business assumption, and maybe last, system performance. If the discussion isn't confined in these areas, it will go nowhere and quickly downgrade to a heated argument without a satisfaction from either parties involved but feelings hurt, self-opinion firmer believed in, and a mine field that no one is willing to step into again.
Really, a particular framework or programming language does not make the design async or sync. Tornado, Twisted, or libs like Asyncio, Gevent, they all have the capability to help an async implementation if needed, but they don't make your design or your architecture async. Fundamentally one can even argue that computer architecture is genetically synchronous because CPU can execute one instruction at a time, unless multicore can be utilized, and I do mean they are utilized either by at the HW level where CPU, cache and memory are smart enough to take some instructions for parallel computing, or the higher level interpretation -- assembly, C, or sth even more abstract -- have the design and internal implementation all the way through to generate those instructions that make the CPU smart.
Too many times ppl take multithreading and multiprocessing as the
statement that my code or my design is now asynchronous, or event
drive, or responsive, which all mean the same thing — it's
superior to a synchronous one. Really? How do you validate all the
components on your stack are implemented so support your statement? Is
DB itself asyn capable (and what does this even mean!?)? is the DB
interface lib asyn capable? is the 30+ imported libs, third-party
tools, code you have written, asyn capable? Is the server lib based on
epoll? Is your shell call using
check_call? Is your disk firmware
async? Even step along the stack can bring your system to a halt
regardless how some part of the stack is actually async. So my point
here is async design or architecture is irrelevant because it is
not a technical topic, but a business topic.
Why so? Because what really matters is dependency. Your business workflow is the
single voice that will dictate and define dependency. Use PM for
example, if task A is depending on the completion of task B, then
regardless how multitasking the resource assigned to these tasks are,
tasks are executed in sequence, period, because that's what makes
sense in business, even though it slows the entire system down. Technology
can improve UX by making user's wait more tolerant, but it can not,
and should not, remove the
it breaks business sense. Mapping this argument to an e-commerce app,
if user needs to add to shopping cart, submit checkout, pay, get
receipt — well, clicking that submit checkout button should
BLOCK until it's accepted by server before he is presented with
payment view — sync. What should really be done is sit down and
watch this Tech talk, yes, technology is not a silver bullet
unless you know what you want to get out of it.
Now looking back to my career, funny the only real asyn requirement I have encountered is in china's workflow, the concept of 会签（consensus voting ← this is my phrase), but without a majority rule. Go figure. My implementation is to give everyone a high-five page and not bother to even post data back to the server — everything is handled on client side, no IO blocking concern of any kind, click-at-will and guaranteed consistent and satisfying responsive, realtime, event driven, taking advantage of any HW resource the user happens to have, distributed, HA, zero single point of failure....this, is an asynchronous design.
— by Feng Xia